Yeah, that's the problem :) Not all libraries I want to use, uses Tokio. What about those? Was that really the plan with async in Rust, that I'll get to chose between two ecosystems and if I chose one, I cannot use the other?
Then just put Tokio in the standard library so there is at least some resemblance of consistency in the ecosystem.
Tokio is 1.0 since 2020 and they declared to maintain backwards compatibility for a minimum of 5 years. Tokio already made backwards compatibility guarantees and it hasn't been killed so far.
It isn't a question of backwards compatibility, it is just way easier to iterate / evolve in a crate than it is in stdlib.
For example, Tokio has the concept of "unstable" features, which have stronger stability guarantees than Rust nightly. First, you can use them with the stable rust compiler, second we guarantee that unstable features will not break across patch releases. This may seem small, but it lets us experiment with new functionality and get real world usage. Many of our users cannot use Rust nightly but can use Tokio unstable features.
AFAIK there are no libraries that aren't compatible with tokio or without a direct tokio equivalent. The sad reality is that tokio dominates so hard that it's pointless to even try any other runtime.
Library using async-std instead of tokio for example, which there are plenty out there. Search on crates.io and you'll see. Many support tokio nowadays, but there are still some out there that doesn't. And because of the closed nature of Rust libraries, it's not easy to patch it in there without having to fork the library.
I'm very familiar with the crates ecosystem (I run https://lib.rs). I know there are libraries for async-std specifically, but my point is that AFAIK all of them have equivalents for tokio, e.g. you can't use `surf` with tokio, but there's `reqwest` and others. I'm not aware of any "killer app" existing that would be forcing anyone to use async-std (and if there was one, it'd get forked and converted to tokio ;)
The lack of interoperability between runtimes creates a winner-takes-all situation, which creates a vicious cycle for async-std: fewer people use it, so it has fewer crates supporting it, so it's harder to write software depending on it, so fewer people use it.
If you're bothered by the runtime fragmentation situation, use tokio. Fragmentation doesn't exist for tokio users (there are 10 tokio crates for every 1 async-std crate).
Yeah, that's the problem :) Not all libraries I want to use, uses Tokio. What about those? Was that really the plan with async in Rust, that I'll get to chose between two ecosystems and if I chose one, I cannot use the other?
Then just put Tokio in the standard library so there is at least some resemblance of consistency in the ecosystem.