There are no plans to incorporate a big async runtime like tokio. This does not matches Rust's vision of small, well-focused std.
There are possible plans to implement a minimal runtime that only allows you to execute futures. No I/O or such. Mainly for tests or examples. No timeline though, at least as far as I'm aware.
There are also plans to standardize the async traits, e.g. spawn a new task, AsyncRead and AsyncWrite etc.. I don't think there is a timeline, but they wait at least for async fn in traits.
> I don't think there is a timeline, but they wait at least for async fn in traits.
That was just merged! [1] It should be stable in 1.75 on December 28th.
I know it was merged, but currently there is only support for statically-dispatched async fn in traits. I believe we also need dynamic dispatch to compete with the current style of `poll_X()` functions in the I/O traits.
Fair enough. I'm still excited!
Re:Why Async Rust?
by bryanlarsen on Monday October 16, 2023 @11:08AM
(#37900877)
The article proposes putting "pollster" or similar into the standard library.
https://docs.rs/pollster/latest/pollster/
Technically pollster is a runtime, although in practice it's an anti-runtime.
The async Rust book [0] says this about runtimes:
> Importantly, executors, tasks, reactors, combinators, and low-level I/O futures and traits are not yet provided in the standard library. In the meantime, community-provided async ecosystems fill in these gaps.
Notably, it says "not yet". My question is if someone knows if there are actual plans to incorporate any (existing) async runtime, and if so, whether there is a timeline? Also, is tokio in the talks to be the runtime, or is this still open?
[0]: https://rust-lang.github.io/async-book/08_ecosystem/00_chapt...