Async Rust: Where does the scheduler live?

This piece surveys the common complaints about async Rust by way of a bingo-card list and focused explanations of the underlying technical issues. It catalogs concrete problems such as the scoped-task trilemma (concurrency, parallelism, borrowing), function-coloring and async-closure complexities, Tokio defaultism and runtime-specific assumptions, lazy futures and forgotten .awaits, synchronous Drop in async contexts, select!/cancellation safety, Send/Sync/'static bound proliferation, io_uring integration challenges, embedded executors, Box::pin stack growth, work-stealing versus thread-per-core runtime designs, spawn_blocking footguns, unstable generators/AsyncIterator APIs, and ergonomic deficits around Pin, dyn dispatch, and APIT/RPIT. Each complaint is tied to specific tradeoffs, invariants, or API design constraints and points to further technical discussion.

The central argument reframes the objection that async Rust “requires a runtime” as a misunderstanding: scheduling is inherent to concurrency, so whether scheduling happens in Tokio or the kernel, the same fundamental tradeoffs and complexity appear. Runtime design choices are optimization decisions that expose different constraints (e.g., Send bounds for work-stealing) rather than regressions in Rust’s no-runtime ethos. The takeaway is to treat these as general concurrency-scheduling problems to be reasoned about, not language-level failures, and to evaluate runtimes against the specific tradeoffs they accept.