Async Rust can be a pleasure to work with (without `Send and Sync and 'static`)

https://emschwartz.me/async-rust-can-be-a-pleasure-to-work-with-without-send-sync-static/

by todsacerdoti • 2 years ago

22 4 2 years ago

emschwartz.me

redman25• 2 years ago

I love what the author is proposing.

I’d be curious how this can work while every library feels like it’s infected by Tokio.

emschwartz• 2 years ago

(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.

andrewl-hn• 2 years ago

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!

abrkn• 2 years ago

This is amazing!

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.

Async Rust can be a pleasure to work with (without `Send and Sync and 'static`)

Related Stories