Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Tokio - and Rust's async model in general - is pretty freaking cool, but it isn't a perfect fit for everything. After hammering for a few days, I'm pretty confident that it's not working out here: - There's no way to enforce scoped async tasks without blocking the current thread.[1][2][3] This means that there's no async task equivalent to Rayon/Crossbeam-like scopes, and you're back to arcs and pins and all sorts of fun boilerplate if you'd like to foster parallelism with task::spawn(). - Traits and recursive calls need lots o' boxes, implemented by proc macros at best and by hand at worst. - Since many FS syscalls block, tokio asyncifies them by wrapping each in a spawn_blocking(), which spawns a dedicated thread. Of course you can wrap chunks of synchronous file I/O in spawn_blocking() if kicking off a separate thread for each File::open() call doesn't sound fun, but that means you can't interact with async code anywhere inside... - Add in the usual sprinkling of async/await/join/etc. throughout the code base - since anything that awaits needs to be a future itself, async code has a habit of bubbling up the stack. None of these are dealbreakers by themselves, but they can add up to real overheads. Not just cognitive, but performance too, especially if you've already got a design with concurrent tasks that do a decent job of saturating I/O and farming CPU-heavy work out to a thread pool. < gestures around > [1]: tokio-rs/tokio#1879 [2]: tokio-rs/tokio#2596 [3]: https://docs.rs/async-scoped/latest/async_scoped/struct.Scope.html#safety-3
- Loading branch information