Async Rust: Where does the scheduler live?
5 hours ago
- Async Rust faces many common complaints, including function coloring, complex compiler errors, and the need for a runtime, which some see as a regression from Rust's zero-runtime promise.
- Concurrency inherently requires a runtime for scheduling, whether through async runtimes like Tokio or the kernel with threads, exposing complexity that Rust intentionally does not abstract away.
- The decision to avoid built-in green threads in Rust aligns with its goals for bare-metal performance and embedded use, but leads to challenges like Tokio defaultism, Send bounds, and ecosystem splits.
- Alternatives like Zig's explicit I/O interface passing could solve many issues by making runtimes a passed parameter, though this approach is unproven and would require major Rust API changes.
- Despite frustrations, async Rust's design trade-offs are reasonable given Rust's performance and portability priorities, with many issues being general concurrency problems rather than Rust-specific flaws.