Futurelock: A subtle risk in async Rust

Show context

forrestthewoods ◴[31 Oct 25 21:33 UTC] No.45776951[source]▶

I feel like I’m pretty good at writing multithreaded code. I’ve done it a lot. As long as you use primitives like Rust Mutex that enforce correctness for data access (ie no accessing data without the lock) it’s pretty simple. Define a clean boundary API and you’re off to the races.

async code is so so so much more complex. It’s so hard to read and rationalize. I could not follow this post. I tried. But it’s just a full extra order of complexity.

Which is a shame because async code is supposed to make code simpler! But I’m increasingly unconfident that’s true.

replies(2): >>45777647 #>>45779215 #

amelius ◴[31 Oct 25 22:59 UTC] No.45777647[source]▶

>>45776951 #

Async code is simpler because you're implicitly holding a lock on the CPU. That's also why you should stay away from it: it increases latency. Especially since Rust is about speed and responsiveness. In general, async programming in Rust makes little sense.

replies(1): >>45778182 #

forrestthewoods ◴[01 Nov 25 00:27 UTC] No.45778182[source]▶

>>45777647 #

I love Rust. But I’m 100% convinced Rust chose the wrong tradeoffs with their async model. Just give me green threads and use malloc to grow the stack. It’s fine. That would have been better imho.