May 5, 2026
Await, what?!
Async Rust never left the MVP state
Rust fans cheer the fix, skeptics yell “just use threads,” and everyone argues over the title
TLDR: A Rust developer says the language’s async feature still creates too much extra code and wants the compiler fixed at the source. Commenters split fast: some praised the deep dive, some mocked the dramatic framing, and others reignited the eternal “async vs threads” war.
Rust’s latest mini-drama started with a developer saying the language’s much-hyped async system still feels stuck in its “minimum viable product” era, especially on tiny devices where every bit of memory matters. The post dives into why simple-looking async code can blow up into a surprisingly huge amount of compiler-generated machinery, and argues the real fix should happen inside the compiler itself, not through endless workarounds. In plain English: code that’s supposed to be sleek can turn chunky, and the author wants Rust’s own toolchain to stop wasting space.
But the real show was in the comments. One camp was totally here for the nerdy autopsy, calling it exactly the kind of “ugly but necessary” conversation mature languages have to survive. Another camp instantly turned it into a philosophy war: is async clever progress, or just a fancy detour back to… threads? One commenter basically declared the whole idea undercooked “across the board,” while a Rust defender fired back that critics are obsessing over a few extra bytes while other languages casually drag in whole runtimes and threads.
Then came the lighter shade. One reader praised the article but roasted the headline as a little too dramatic—which, honestly, only made it more clickable. Another brought up a painfully relatable complaint: if you want both async and normal versions of the same feature, you may end up writing things twice. So yes, this was partly a compiler deep dive, but mostly a classic internet brawl over hype, design, and whether Rust is being held to impossible standards.
Key Points
- •The article argues that async Rust still produces significant binary-size bloat and that the root cause should be addressed in the compiler.
- •It is presented as part 2 of a series, shifting from coding work-arounds to compiler-level analysis and optimization ideas.
- •The article excludes the separate issue of oversized futures and excessive copying, while noting an open Rust pull request addresses part of that problem.
- •Using a small `foo`/`bar` example, the article shows that async lowering in MIR generates substantially more code than a non-async equivalent.
- •The article explains that generated futures include states such as `Returned` and `Panicked` to preserve `Future::poll` safety, then questions whether panicking after completion is necessary.