Drop support for async-std?

[thomaseizinger]

I'd like to discuss the idea of dropping support for async-std.

Benefits:

• Simpler library interface, because there is only one of each transport, behaviour etc
• Less code to maintain
• Smaller dependency tree

Disadvantages:

• Users of async-std need to start a separate tokio runtime to use libp2p

---

tokio is a much more actively maintained library. async-std has not had a release in over a year and even the previous ones were rather minor: https://github.com/async-rs/async-std/releases

I'd suggest that we still have a tokio feature flag (this is important for WASM compilation). Thus, I believe there would be no footguns around running on the wrong executor.

Due to the modular nature of things, support for async-std could also be maintained out-of-tree if someone is interested.

[Tanguille]

Can I take from this that the recommendation is to use tokio now? I was suprised to see the tutorial using async-std hence why I looked for this discussion. This might need an update if it is indeed the new recommended way to use libp2p in rust.

[thomaseizinger]

We don't really recommend one over the other. With recent improvements, both runtimes should be equal citizens in the library. Personally, I prefer tokio because it is the more maintained ecosystem.

[Tanguille]

Okay that's clear. I'll keep using tokio aswell since that's what I have used since I started with rust. Never saw async-std used so I assumed it would been deprecated.

[mxinden]

I was suprised to see the tutorial using async-std

In case you are up for a contribution, I would welcome a pull request moving the existing examples to use tokio instead of async-std.

[jxs]

As we spoke in the community call, agree with the decision Thomas

[thomaseizinger]

I've opened #4449 as one action item from this discussion. At a later point, we can decide whether we want to actually drop support for it.