Was Rust Worth It?

Pasting in an error message, made chatgpt spit out another version of the code with some other error.

1. Reading the error messages. I was used to error messages verbosely printing a lot of details which were mostly irrelevant and letting the programmer sort it out, and I developed a habit of skimming them. I had a better time with Rust when I realized it was giving me information that was mostly relevant, and that I should actually read them.

2. Interpreting error messages as feedback rather than failure. I was used to error messages meaning I had done something wrong, and getting them all the time was frustrating. Watching Jon Gjengset's coding videos, I was struck that he wrote code to trigger errors deliberately in order to get feedback from the compiler. I now try to work through Rust error messages the same way I would failing unit tests; I make some small changes, I knock out the errors, and then move on to the next subtask. This keeps the number of errors small and manageable, and gets me into a tight feedback loop with the compiler.

Relatedly, I encountered the idea (in a blog post I no longer remember) that the Rust compiler is more like an automated pair programming partner than other compilers. This change in mindset really helped for me; thinking of it as a friendly helper rather than a loud complainer made the work lighter. (That's why I personally don't like the 'abusive partner' metaphor, for me that mindset makes it toilsome and miserable. Also because I've had an abusive partner, and it's nothing like that, and I could do without the reminder.)

3. Setting up my IDE to show me inline type annotations and error messages. This made the feedback loop tighter, I only have to drop into a terminal for complex or unfamiliar error messages. With practice I can fix most errors using a one-line summary.

4. With practice, I've internalized Rust's semantics, and I've stopped painting myself into corners with unnecessarily cyclic data structures and such. I also read a blog article or maybe a tweet (which I've also forgotten) about giving yourself permission to use Box or clone and not sweating every copy or allocation. It pointed out that if you were writing Python, everything would be an Arc, and you'd think nothing of it; in Rust the performance cost is explicit, so you agonize over it, but a lot of the time it's not a big deal to copy some data or to perform an allocation.

Hey, I resemble that remark.

But I disagree with it. Green threads give you all the advantages of async, but with less of the hairs. In particular no special syntax or change of programming style is required. Yet underneath green threads and async just different styles of event driven I/O, so both run at similar speeds and excel at the same tasks. (Actually green threads should run faster, as storing state on a stack is generally faster than malloc.)

I have no idea why Rust abandoned green threads in favour of async. Actually, that's a partial lie - there have been far too many words wasted on explaining why. The problem is the reasons they give look to be an caused by design decisions they made in their implementation. The primary objection seems to be speed. The current async is indeed faster than their old green thread implementation. But that was caused by their choosing to avoid coloured code in their green threads (maybe they were copying Go?). Other objections were similarly to do with the implementation they threw away, not green threads themselves.

Once you stop fighting the fact that tokio = async rust for 99% of cases, things are quite smooth.