"""smol (likely discontinued, since author left rust)""" doesn't seem well supported and smol is used by async-rs these days iirc.
[0]: https://github.com/async-rs/async-std
Most libraries can be used with different runtimes. Hyper for example, which uses Tokio by default, can be configured to use an async-std executor.
I'd be very interested in hearing other opinions, as my Rust project [1] is currently stuck on an older version of Tokio while I wait for deps to update. I'm either going to have to bite the bullet and replace deps or bite more bullets and find a different runtime.
As I understand it, that difference (vs Tokio) was the main driver behind the projects splitting.
I also think it's a bit presumptuous for them to name themselves "std". It'll be even more ridiculous in the likely event that Tokio becomes the std:: asynchronous I/O library. It's asking for confusion.
do you have an example?
Either way, "can be configured" means that custom code for each runtime must be written, it is not like lets say "Futures", which can be used generically.
You do have to write a ~50 loc compat layer. However, most of the compat layer is due to the fact that tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures crate, which may change in the future [0]. After that, you just have to implement `hyper::Executor` for async-std's `spawn`, and `hyper::Accept` for async-std's `TcpListener`.
Of course, it is not as generic as "Futures", but it is relatively simple to do. As @steveklabnik mentioned above:
> There's a few points here that still need some interop work. The intention is to fix that, but it's non-trivial. We'll get there.
The standard futures library does not have an AsyncRead or AsyncWrite:
https://docs.rs/futures/0.3.8/futures/io/trait.AsyncRead.htm...
vs
Stjepang is a very smart person and I'm actually quite excited about what he's going to bring to the Go world.
https://webcache.googleusercontent.com/search?q=cache:PRjMyv...
Whoa. smol is great. Why’d the author leave?
If you're writing a library to be used by others you can very often expose only types which come from std::futures. The result will work with all of the runtimes.
I'm currently using smol (in an application I'm developing - not just a library) and I don't think this will scare me away. He appears to still be responding to pull requests, and smol consists of a reasonably small amount of very high quality code.
Using runtime-specific features and APIs ties you to a specific runtime.