Async Rust never left the MVP state

Original Article ↗ Hacker News Discussion ↗

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.