2 days ago
- The author began using Rust in 2017 and views async Rust as complex due to its combination with Rust's unique constraints, not poor design.
- Many applications may not need N:M threading (like async) because modern computers are fast enough for OS threads, but developers still want it for Rust to compete with Go and C++.
- Rust's zero-cost abstraction goal prevents adopting Go-like async models that require a heavy runtime, as seen with the removal of green threads.
- Issues with Arc and Mutex in async Rust are actually general concurrency problems, not unique to async, and stem from poor design thinking rather than async itself.
- Async Rust faces 'crate coloring' where most IO-related crates are async, forcing sync programs to pull in async dependencies, and Tokio dominates the ecosystem, limiting executor choice.
- The language lacks async support for traits, Drop, and closures, making async a second-class citizen, though effect system extensions are being explored.
- The sans-IO pattern inverts control by separating IO from logic, allowing code sharing across sync and async implementations and reducing dependency bloat.