6 ms·
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 au
by rossmohax 6y ago
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.
- ibraheemdev 6y agoasync-std [0] is pretty widely used as well. [0]: https://github.com/async-rs/async-std 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.
- mmastrac 6y agoI 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. [1] https://github.com/mmastrac/stylus/ https://github.com/mmastrac/stylus/
- rossmohax 6y agoCan't find async-std feature here: https://github.com/hyperium/hyper/blob/master/Cargo.toml https://github.com/hyperium/hyper/blob/master/Cargo.toml 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.
- ibraheemdev 6y agoHere is an example: https://github.com/async-rs/async-std-hyper/blob/master/README.md https://github.com/async-rs/async-std-hyper/blob/master/READ... 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. [0]: https://github.com/tokio-rs/tokio/issues/2716 https://github.com/tokio-rs/tokio/issues/2716
- octoberfranklin 6y ago> tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures The standard futures library does not have an AsyncRead or AsyncWrite: https://doc.rust-lang.org/std/future/index.html https://doc.rust-lang.org/std/future/index.html
- ben0x539 6y agoProbably in reference to https://docs.rs/futures/0.3.8/futures/io/trait.AsyncRead.html https://docs.rs/futures/0.3.8/futures/io/trait.AsyncRead.htm... vs https://docs.rs/tokio/1.0.0/tokio/io/trait.AsyncRead.html https://docs.rs/tokio/1.0.0/tokio/io/trait.AsyncRead.html
- 6y ago
- octoberfranklin 6y agoIt 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.
- deleted 6y ago[deleted]
- forrestthewoods 6y ago> and there is smol (likely discontinued, since author left rust) Whoa. smol is great. Why’d the author leave?
- ibraheemdev 6y agoSince when did Stjepang leave Rust?
- rossmohax 6y agohe posted a goodbye issue on a smol repo, but since then deleted it, so maybe he changed his mind
- gpm 6y agoI 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. https://webcache.googleusercontent.com/search?q=cache:PRjMyvtBYUoJ:https://github.com/smol-rs/smol/issues/214+&cd=15&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:PRjMyv...
- indepnd 6y agoThanks 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.
- jedisct1 6y agoHe switched to Go. Stjepang is a very smart person and I'm actually quite excited about what he's going to bring to the Go world.
- earwaxauditor 6y agoRust/Go really are the Emacs/Vim of programming languages: little in common but commonly mentioned in the same breath.
- volta87 6y agoWas there a blogpost? Or when/where was this announced?
- WhatIsDukkha 6y agohttps://github.com/stjepang?tab=overview&from=2020-12-01&to=2020-12-23 https://github.com/stjepang?tab=overview&from=2020-12-01&to=... """smol (likely discontinued, since author left rust)""" doesn't seem well supported and smol is used by async-rs these days iirc.
- deleted 6y ago[deleted]
- jayd16 6y agoIf core rust provides an interface for async/await why does usage of it tie you to a specific runtime? Whats the point of that?
- steveklabnik 6y agoUsage of it, on its own, does not tie you to a specific runtime. Using runtime-specific features and APIs ties you to a specific runtime.
- jayd16 6y agoIs 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?
- steveklabnik 6y agoI 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.
- Xevi 6y agoWoah, I didn't know about that. Does this mean Rust only has one maintained runtime now? Namely Tokio.
- sanxiyn 6y agoI think it's rather that smol is "complete" and doesn't need much maintenance.
- Xevi 6y agoMaybe 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.
- gpm 6y agoOne 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.
- FridgeSeal 6y agoAsync-std is still actively maintained and developed.
- octoberfranklin 6y agoThat'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.