Favor tokio over async-std

[umgefahren]

State of things

rust-libp2p currently favors async-std over tokio. I.e. the majority of the examples use async-std, AsyncRead and AsyncWrite are the traits async-std uses and the default features include async-std not tokio.

async-std vs tokio

Feature	tokio	async-std	Comment
WASM	👍	👎	Although both runtimes support WASM now, Tokios support seems to be more advanced and also allows networking on WASI.
Popularity (Recent downloads)	10.260.791	1.327.098	I consider this the most important argument. Tokio seems to become the de-facto standard for async Rust in the future.
Ecosystem	👍	👎	Tokios ecosystem is growing fast and the debugging tools are more advanced. Especially tokio-console is a huge quality of life improvement.
Documentation	👍	👎	Tokio gives a very good and gentle introduction into async in Rust, thus it makes libp2p possibly more accessible.
Activity (GitHub)	👍	👎	At the time of writing the last commit in Async-Std was over a month ago, while tokio had it's last commit 4 hours ago.
Migration cost	👎	👍	It would take effort to migrate from async-std to tokio.

Of course I'm just expressing my opinion here. I'm very open for good reasons to stay with async-std and open to discussions 😃

[thomaseizinger]

Thank you for your post!

Personally, I'd be in favor of that too. From the project's perspective though, I think we should not favor any particular runtime, at least when it comes to the feature design.

I've already put down a few thoughts around this here: #2173

Re-designing the features would have the biggest impact IMO. Another problem that would be good to fix is #2173.

We'd very much appreciate help on this front.

[dariusc93]

I honestly dont mind this, although this is assuming its just for examples and not ditching async-std for tokio altogether, unless otherwise needed to be done for whatever reason though to my knowledge there havent been any issues with async-std (despite its current stats). As @thomaseizinger said, libp2p shouldnt really favor a specific runtime especially given that people still use tokio or async-std for different reasons. Could be for footprint, design, functionality, etc., though I have always preferred tokio due to better documentation.