Re:Tokio: Runtime for writing reliable asynchronous applicat...
by zamalek on Tuesday April 28, 2020 @01:48AM
(#23003829)
The purpose of tokio was to add asynchronous support to Rust in the absence of async features (it predates them). It has since added std-like async interfaces. It is the most mature.
async-std aims to do that last sentence as cleanly as possible, without having to support a legacy interface. I found it builds faster because of that and that's why I chose it.
smol (the new kid in the block) aims to async-ify network types by simply wrapping them in Async<T>. It also aims to be as few lines of code as possible.
They are all different approaches to the same problem. The ability to experiment with different approaches is precisely why Rust doesn't have a prescribed async runtime (or prescribed error types, or many other things).
If merely solving the problem is all you care about, pick tokio. It should be able to use async-std crates, but async-std can't use it. smol can use anything but is a bit unproven.
async-std aims to do that last sentence as cleanly as possible, without having to support a legacy interface. I found it builds faster because of that and that's why I chose it.
smol (the new kid in the block) aims to async-ify network types by simply wrapping them in Async<T>. It also aims to be as few lines of code as possible.
They are all different approaches to the same problem. The ability to experiment with different approaches is precisely why Rust doesn't have a prescribed async runtime (or prescribed error types, or many other things).
If merely solving the problem is all you care about, pick tokio. It should be able to use async-std crates, but async-std can't use it. smol can use anything but is a bit unproven.