(Author here) I'm glad you liked the post/proposal!
That's a good question. I think the tie-in with Tokio mostly relates to a couple of things:
1. calls to `tokio::spawn`
2. async I/O traits like `AsyncRead`/`AsyncWrite`
3. direct usage of Tokio I/O
For 1, it would be great if more libraries switched to using more structured concurrency primitives instead of using spawn. In the cases where it does make sense to have a spawning function, it would be nice if they used crate-exported traits like [hyper::rt::Executor](https://docs.rs/hyper/latest/hyper/rt/trait.Executor.html) so that the functionality could be abstracted over different runtimes.
For 2, hopefully those traits will eventually be standardized in std.
For 3, it would also be nice if the necessary functionality were abstracted into crate-exported traits that were implemented for the Tokio structs.
Buuuut, all of that said. It's thorny and a lot of the ecosystem is indeed wedded to Tokio.
> For 2, hopefully those traits will eventually be standardized in std.
We got async functions in traits, but we can't create trait objects with these traits yet without using a separate crate and without boxing. Once it will be possible this would mean that projects like embassy can rely on these traits in environments that don't allow heap allocations. Another relevant feature is async iterators / streams. This would be the point when these traits will be standardized. We are probably 1-2 years away at this point.
Tokio and other runtimes meanwhile made effort to be ready for when these traits become standard: tokio keeps all relevant `read` and `write` methods in custom `AsyncReadExt` / `AsyncWriteExt` traits so that when a standard version of these methods appears people won't end up with conflicting implementations and broken code.
Great post: it's something I wanted to write for the past 2 years or so and I'm glad this post exists now. Thank you so much!
I've been rewriting a project from Node.js (TypeScript) to Rust that has a large number of nested async tasks running. Using `moro-local` I was able to remove all the `JoinSet`, `Arc<Mutex<...>>`, and write a very similar style as I had in Node.js.
I’d be curious how this can work while every library feels like it’s infected by Tokio.