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.
Same story can happen with time/decimals/database drivers.
However pulling it into std would probably kill the library because backwards compatibility guarantees.
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.
I didn't imply anything about Tokio. I just wish some libs didn't need to be bikeshedded (like async runtime, time, decimal, etc.)
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.
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).