Async Rust never left the MVP state

Original Article ↗ Hacker News Discussion ↗

Async Rust’s current design is criticized as still feeling like a minimally viable product, especially in embedded and no-std contexts where the size and layout of futures and state machines impose noticeable overhead. Commenters debate whether these costs violate Rust’s “zero-cost abstraction” ideal, touching on issues like function coloring, lack of aggressive compiler optimizations, and the absence of a standard async runtime versus de facto reliance on Tokio. Others counter that Rust’s trade-offs enable use in domains where green threads or heavier runtimes are impractical, and argue that incremental work on compiler optimizations, async traits, and potential effect systems could address many of today’s pain points.

Perception of the Title and State of Async Rust

  • Many see the title (“never left MVP”) as exaggerated or click‑baity; some call it borderline misleading, others defend it as directionally true because the core async machinery hasn’t evolved much since stabilization.
  • Several commenters stress that the article is motivated by love of Rust and heavy async use, not by “hating on Rust.”

Performance, Code Size, and Embedded Constraints

  • A recurring theme: small futures and fewer state variants matter on microcontrollers and other no‑std / constrained systems (RAM, flash, compile times).
  • Some dismiss the focus on trivial-function overhead as micro‑optimization; others note empirical 2–5% binary size reductions and ~3% perf gains from early compiler experiments.
  • There’s concern about code bloat when many “logically sync” functions must be async (e.g., trait methods with mixed sync/async implementations).

Async Model, Function Coloring, and Possible Fixes

  • The “function coloring” problem (sync vs async duplication) is widely acknowledged. Crates like maybe‑async and sans‑io patterns are discussed as partial workarounds but with limitations.
  • Future directions mentioned: keyword generics, algebraic effects, and an “effects initiative” to make code generic over async/const/etc., though progress appears slow/uncertain.
  • Some argue Rust simply “missed” with its async design; others counter that for a systems language with zero‑cost FFI goals, the trade‑offs are reasonable.

Threads vs Async vs Green Threads

  • Big debate:
    • One side: traditional threads (or green threads) are the “right” mental model; async/await is a workaround for performance issues or missing threading.
    • Other side: OS threads are too heavyweight for fine‑grained I/O concurrency; async with work‑stealing executors offers better scalability and latency.
  • Green threads (Go, Java virtual threads, etc.) are praised for ergonomics but critiqued as incompatible with Rust’s zero‑cost and FFI goals.

Runtimes, Tokio Dominance, and Standard Library Role

  • Concern that the ecosystem is overly dependent on Tokio, analogous to a third‑party GC being de facto standard.
  • Some want standard traits and a default executor in std (like the global allocator), with overridable implementations.
  • Others warn that standardizing a runtime could freeze a suboptimal design and reduce flexibility across platforms (servers vs embedded, single‑threaded vs work‑stealing).

Ergonomics, Learning Curve, and Overall Sentiment

  • Several commenters feel async Rust is much less “joyful” than the rest of the language and reach for threads instead.
  • Others argue async Rust is still better than most languages’ async, especially given its applicability to embedded, kernels, and no‑std contexts.