Tokio comparison

[bugproof]

I think having such comparison would be very helpful for people new to Rust trying to understand async ecosystem mess. Why would I want to use async-std over tokio? How can I answer this question?

https://www.reddit.com/r/rust/comments/l1rnn6/is_asyncstd_a_second_class_citizen/

[wodny]

And what might be even more important - is the project dead?

[yoshuawuyts]

And what might be even more important - is the project dead?

It's not, though I understand why you might get that impression. The primary focus for async-std has always been to explore both how we could create an implementation optimized for maintainability, and expose rich APIs which balance ease of learning and high performance. It's not just been to create a runtime which gains some popularity but ultimately falls short in an important way (we've been there, done that [1], [2], [3]). But to explore new language features ¹, find out ways in which the fall short, and find out what we don't know. And then improve on that. Which we continue doing that to this day.

Early on in 2020 we pivoted from working actively in the async-std codebase, and instead started work in different ways:

• Stjepan started the smol-rs project, with the goal of making async-std's flexible internal design re-usable by other runtimes. He believed that building your own runtime shouldn't have to be rocket science, and smol-rs succeeded at that proving it doesn't.
• I started exploring ways in which we could lift our learnings from async-std into the stdlib and language. I've been active in progressing async features in the stdlib, for example by helping author and implement the Stream RFC, implementing IntoFuture, helping stabilize Wake, and implementing thread::available_parallelism (stable in 1.59). I've also been writing extensively about async Rust, covering core semantics and exploring ways in which we could extend Rust's stdlib with async functionality. Which is all proving to be useful to the Rust Async WG today.
• Florian became involved with the core team around that time as well, next to the company he manages.

We made one core change to async-std during this period: we switched out most internals from what we had before, to using the smol-rs variants. The latest updates to smol-rs were made last week; so even if it's not directly obvious, async-std keeps gaining in stability and performance under the hood. We also gained and lost some contributors during this period. Marc-Antoine and Friedel both have contributed a lot during this time. And covering even more recent developments: I don't believe Stjepan works in Rust at all, I've been given more time to work on async Rust through work, and Florian is no longer on the core team.

But the work hasn't stopped. The smol project might be "done" in scope, but still actively receives updates. And the features marked "unstable" in async-std continue on a steady path to stabilization (see: progress). Unfortunately we don't have well-funded teams dedicated just to maintaining async-std, so we have to choose what we focus our resources on ². But the work goes on. And async-std keeps improving.

Anyway, this is probably more of an answer than you were expecting. I've seen this question pop up a few times recently, so figured I might as well answer it. I hope this sheds some light on what we're doing, and what we're up to.

---

As for "how does async-std compare to tokio?". tokio is and has always been the more popular runtime. It's well-maintained, performs well, and you're unlikely to be questioned for using it. But I'm proud of the work we're doing on async-std, and think we have and continue to push the bounds on ergonomics and user experience. Which one is right for your needs is for you to decide.

Footnotes

1. Note that async-std reached 1.0 back in 2019, soon after async/.await was stabilized. When we started work on async-std it was unclear whether any other runtimes would adopt async/.await, and we thought it was important for a native runtime to exist when the feature went live. ↩

2. answering issues and thrifting through PRs takes an enormous amount of time. That's likely the biggest thing we haven't been doing enough of. ↩

[wodny]

Anyway, this is probably more of an answer than you were expecting.

This kind of answer is great. Thank you very much for that. It gives context, an actual insight and allows for a proper interpretation of project/repository statistics, otherwise hard to evaluate.

[zzy]

@yoshuawuyts Great answer. Thank you!