TWiR quote of the week

A conversation on Mastodon between @kroltan and me about Bevy Game Engine:


If I should describe #Bevy #BevyEngine in one word, it is this:


Answer by @kroltan (which is the quote I'm nominating):

  • Modular
  • Very high quality construction compared to its competitors
  • If you leave it lying around forget about it, stepping into a project is painful?

I nominate in

woah, rustc does a better job of explaining merge markers than git does :eyes:

Source (sorry, seems to require matrix login to view)


To see an example in the playground


Given that the most recent QOTW was one of mine (and it was much punchier), I'm dropping this here more because I wanted to share something that I had a "Did I just write that? :)" moment over than because I expect it to get picked:

If your metric of safety is a context like a self-driving vehicle, where crashes of ANY kind are a problem, you can't claim that an exception-based language like the C# vehicle in the DARPA challenge is "safer than" Rust when arguing to keep C++. Those crashes aren't "about" memory safety. They're about implicit control flow paths that slipped through compilation to be caught at runtime.

-- ssokolow on YouTube in the context of commenting on something ThePrimeagen was reading

(Specifically, the "Think about Rust as being better on implicit control flow, not merely on the subset of it concerned with memory safety" sentiment.)


Thats the main reason I stuck with Rust.

1 Like

The functional ML roots of the language, Graydon's first Rust compiler was written in OCaml, shine through, influencing it right from the start.

It's not "C++ but better".

It's Haskell standing on Lisp's shoulders, hiding in C's coat to sneak into PRDCTN. (The fancy nightclub where all the popular language's hang out)

const fn: Pure Functions in Rust - No Boilerplate


If C is like playing with knives and C++ is juggling chainsaws, Rust is like parkour suspended from strings and wearing protective gear. It'll look ridiculous at times, but you'll be able to do all sorts of cool moves that would otherwise be damn scary or outright impossible. You'll have so much fun you'll start trying to do it in other languages, too. And many of us never look back

By loggiq, quoting himself on reddit


rust (as I've heard others say) "makes the easy stuff harder in order to make the harder stuff easier"

By anothersteavest on reddit.


I had suggested this quote, too, then watched the rest of the video, and finally decided to delete my suggestion again. While I like the quote, I fully disagree with multiple core statements in the video around it, which presents const fn as if it was an effects system marked to indicate “pure functions”. Which it isn’t. It’s meant to mark “functions that can run at compile-time”, no more, no less. Even weirder is the other thing the video says that “const fn means pure at Runtime”. While I understand the intention[1], in my view it’s actually more true that const fn only fully guarantees (some notion of) purity at compile-time, since (at least internally) API like const_eval_select exists.[2]

The video also calls up mutation generally as a “side-effect”. It explicitly presents how const fn doesn’t support &mut references as a demonstration for how side-effects are prevented, despite the facts that &mut reference will be supported in const fn, and mutation through &mut references (i.e. without interior mutability) arguably don’t constitute “side effects”.

(How &mut references are arguably side-effects-free mutation, would be one of the main points I would have expected from an explanation for a quote like the one in question that “The functional roots of the language […] shine through”.)

TL;DR It’s a nice quote, but (unlike most other videos on the channel which are great), I wouldn’t recommend this video, at least not without further commentary. (Sure there are parallels between effects systems and purity vs. const fn, but it shouldn’t be forgotten that const fn is not designed for anything beyond its core purpose, marking functions that can be executed at compile-time, which can be used to define constants, to initialize static values, or to set const generic parameters such as array lengths).

  1. that compilation itself can have side-effects, such as … well IIRC the arguably bad example given in the video was reading an environment variable, which I would classify wholly under “input to the compilation”, and reproducible compiles are desired anyways… and also that happens through a macro and has nothing to do with evaluation of a const fn at compile-time ↩︎

  2. We’ll have to see in what forms that might or might not get exposed more properly for stable Rust in the future; as of now, I’m only aware of things like panic-handlers that can execute side-effects, but then that’s only in cases where the const fn doesn’t really end up returning at all. ↩︎


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.


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... ↩︎


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.


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.


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.


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


By Simon Ask Ulsnes, from libyaml-safer


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.


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.