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