It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.
I always get a weird vibe from async-std. I respect the people working on it, but it feels like it's trying to boil the ocean.
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.
It bugs me that that library will spin up a scheduler without being asked to do so.
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.
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.
I found the github issue in Google cache. I'm not sure it's really fair of me to post this link here, but equally I think it's better to give the actual text rather than leave it vague.
Thanks for the pointer! It's really sad to hear this. I'm using smol in my project and really like it. I didn't know the author left until now. It's a great loss for Rust, in my opinion.
That's not entirely true. If you want to write an entire standalone application that compiles into a binary and starts up a scheduler, then yes, you have to pick a scheduler runtime.
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.
Maybe that's true. I don't know how complex these things are, or if they will be affected by future changes in the language, but it feels weird to say that a critical piece of software is complete. I wonder if many new libraries will use Smol.
One of the principles that stjepang was very keen on for smol was that libraries shouldn't depend on it. Libraries should be written in an async-executor generic way and the end binary should then be free to use smol as the executor, or tokio, or anything else.
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.
Is this just an artifact of the current work in progress state of things? Is it just a matter of the interface settling and library authors providing a bit more configuration options to become runtime agnostic?
I am not a super expert in all of the exact details, but my understanding is that generally, there are a few features that don't have a common trait yet. For example, "spawn me a new task." Once those traits exist, libraries can be written against them, and it'll all be agnostic. But you only even run into that kind of problem if you need that specific API in the first place.
