3 ms·
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 the
by capableweb 4y ago
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.
- pornel 4y agoI'm very familiar with the crates ecosystem (I run https://lib.rs 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).