TWiR quote of the week

A pretty extension of the cargo-geiger metaphor that I just wrote as part of replying to a forum regular infamous for being abrasively opinionated over on Phoronix:

That's why cargo-geiger exists. To make it easy for people to identify which dependencies contain unsafe-ium so they can check whether their authors are following proper handling practices.

I followed it up with this, but I don't think this part is suited to QOTW, even if it is a somewhat grin-inducing way to extend the metaphor:

(Hell, that's why people using Rust prefer it to C++. In C++, they can't get a signal because everything is full of alpha-emitting unsafe-ium isotope contamination.)

Alpha emitters may be pretty safe as long as you don't swallow any particles, but they sure mess with the signal-to-noise ratio.

8 Likes

Self-nominating this quote:

Every time I choose Rust for a challenging programming problem it does its best to make me regret it, and then I come out with a stronger conviction to use it again next time. Rust's appeal is mostly masochistic; convince me otherwise.

From Implementing the Raft Consensus Algorithm with David Beazley – Brian Kung

1 Like

Ok, I'll try. Real masochism is maintaining a large C codebase in production written by a single developer without the normal checks and balances of a test suite or automated static analysis tools [1]. You haven't felt masochism until you are interrupted while at the cinema, out to dinner with your significant other, sleeping, (or any other activity that is as far away as you can get from having bad code on your mind) because the code randomly crashes and you're on-call to address it immediately.

Even if the only thing ever done to such a mismanaged product is rewriting it in safe Rust, it will save you from many unnecessary wakeup calls induced by hidden UB gremlins littered throughout the C codebase.


  1. Go on, ask me how I know... ↩︎

8 Likes

Oh, here's a good one from reddit:

The sheer stability of this program is what made me use rust for everything going forward. The social-service has a 100% uptime for almost 2.5 years now. It’s processed 12.9TB of traffic and is still using 1.5mb of ram just like the day we ran it 2.5 years ago. The resource usage is so low it brings tears to my eyes. As someone who came from Java, the lack of OOM errors or GC problems has been a huge benefit of rust and I don’t ever see myself using any other programming language. I’m a big fan of the mindset “build it once, but build it the right way” which is why rust is always my choice.

https://old.reddit.com/r/rust/comments/1ach3ir/what_were_some_of_the_first_useful_applications/

16 Likes

The "solution" is "don't do that." But Rust exists because we dare to believe that "don't do that" isn't a great solution, and there are better options available.

CAD97 on IRLO.

10 Likes

Paragraph breaks mine:

My take on this is that you cannot use async Rust correctly and fluently without understanding Arc, Mutex, the mutability of variables/references, and how async and await syntax compiles in the end. Rust forces you to understand how and why things are the way they are. It gives you minimal abstraction to do things that could’ve been tedious to do yourself.

I got a chance to work on two projects that drastically forced me to understand how async/await works. The first one is to transform a library that is completely sync and only requires a sync trait to talk to the outside service. This all sounds fine, right? Well, this becomes a problem when we try to port it into browsers. The browser is single-threaded and cannot block the JavaScript runtime at all! It is arguably the most weird environment for Rust users. It is simply impossible to rewrite the whole library, as it has already been shipped to production on other platforms.

What we did instead was rewrite the network part using async syntax, but using our own generator. The idea is simple: the generator produces a future when called, and the produced future can be awaited. But! The produced future contains an arc pointer to the generator. That means we can feed the generator the value we are waiting for, then the caller who holds the reference to the generator can feed the result back to the function and resume it. For the browser, we use the native browser API to derive the network communications; for other platforms, we just use regular blocking network calls. The external interface remains unchanged for other platforms.

Honestly, I don’t think any other language out there could possibly do this. Maybe C or C++, but which will never have the same development speed and developer experience.

I believe people have already mentioned it, but the current asynchronous model of Rust is the most reasonable choice. It does create pain for developers, but on the other hand, there is no better asynchronous model for Embedded or WebAssembly.

https://old.reddit.com/r/rust/comments/1ai1a97/let_futures_be_futures/korxtar/

5 Likes

For some weird reason the Elixir Discord community has a distinct lack of programmer-socks-wearing queer furries, at least compared to Rust, or even most other tech-y Discord servers I’ve seen. It caused some weird cognitive dissonance. Why do I feel vaguely strange hanging out online with all these kind, knowledgeable, friendly and compassionate techbro’s? Then I see a name I recognized from elsewhere and my hindbrain goes “oh thank gods, I know for a fact she’s actually a snow leopard in her free time”. Okay, this nitpick is firmly tongue-in-cheek, but the Rust user-base continues to be a fascinating case study in how many weirdos you can get together in one place when you very explicitly say it’s ok to be a weirdo.

- Wiki - ElixirNitpicks

7 Likes

By Simon Ask Ulsnes, from libyaml-safer

10 Likes

Nice but "nebulous promises of safety and correctness."? Really?

Rust's rules for memory safety are well defined and rigorously enforced, are they not? Quite the opposite of nebulous.

Of course Rust makes no promises about the correctness of your code. It does not know what it is you are trying to do.

2 Likes
7 Likes

A computer vision engineer mentioned to me recently that they haven't seen a segfault in more than a year. It took a moment to realize how shocking that would have been to me in a previous role as a C++ developer. After a few years using Rust, we've mostly forgotten what it's like to deal with crashes due to bad pointers.

Lots of good quotes in here, actually.

10 Likes

A YouTube video comment:

I'm reminded of the whole "in c easy things are easy and hard things are hard, whereas in higher level languages its the opposite". If you have hard things that are easier to define than easy things, it incentivises overcomplicating things. Rust gives us a bunch more abstractions than c, but keeps easy things easiER than hard things, which is the correct thing if you want to incentivise simple solutions.

YouTube link: https://www.youtube.com/watch?v=XkCHjuF5Qps

1 Like

We are Rust developers, we have principles and compiler enforced moral superiority.

Zack Mitchell : RustConf 2023 - Async building blocks: A streaming Data Drama in Three Acts https://www.youtube.com/watch?v=hU-lKbAdOUg

6 Likes

About a year after I joined Cloudflare, our brand new “DDoS team” realized that we needed to greenfield a total rewrite of our detection and mitigation stack, because Cloudflare was expanding into markets that the existing stuff just couldn’t adapt to support. I spent a month or two skunkworks’ing a prototype in C++ with the hope that what I learned would give us a solid architectural foundation for the the project once it kicked off and we got more resources.

This was a year or two after the massive Cloudbleed disaster happened. Cloudbleed was caused by a memory-safety bug, and as a result our CTO banned teams from starting any new projects using memory-unsafe languages, which was something I hadn’t known at the time. My EM asked me to port it to Rust instead, and needless to say, I was annoyed. It felt like a huge risk and a waste of time to learn/use this niche language. I was sure that forcing the whole team to learn Rust was going to slow us down and push our delivery date back.

I was right: it was a risk, and it did slow us down. However, by being forced to use Rust, we ended up with a better design that was safer and easier to debug, and it was just as fast as the C++ equivalent. In the long run, it was a massive win. We’re all in love with Rust now, and 5 years later we’ve replaced nearly all of our non-Rust code (mostly Go) with faster, safer, and better-architected Rust equivalents.

From Are there any good reasons to use C++ over Rust for new projects today? on lobste.rs

15 Likes

From reddit (link):

u/desiringmachines (withoutboats):
Here's the tracking issue for inherent associated types: Tracking issue for inherent associated types · Issue #8995 · rust-lang/rust · GitHub

u/protestor:
It's from 2013??

u/desiringmachines:
many such cases

3 Likes

From a discussion about crates.io checks on new crates, where the context from kpreid is important:

11 Likes

This just has to be the one.:rofl:

Can you imagine having a genie, or an oracle, which just tells you whether you did something wrong? The closest comparison I have is the way some people talk about programming in Haskell or in Rust, where after half an hour of siege warfare against the compiler, it agrees to build something, and you can be confident that it won’t have certain kinds of bugs.

From Is something bugging you?.

3 Likes

As a sidenote, Antithesis is a very interesting testing solution. I'd love to be a fly on the wall when they're onboarding some of their customers.

Shared mutable state is evil, and you can solve it by forbidding mutation, or by forbidding sharing. Rust supports both.

@kornel on lobste.rs From 1s to 4ms | Lobsters

15 Likes