4 ms·

async-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

async-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 ago
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. [1] https://github.com/mmastrac/stylus/ https://github.com/mmastrac/stylus/
- aliceryhl 6y ago
  Warp should be out pretty soon. It was mainly waiting for hyper, which is already out for 1.0.
  - mmastrac 6y ago
    Ah thanks. I researched this a while back and it didn't seem like there was any ETA but perhaps I can just wait for a bit now.
rossmohax 6y ago
Can'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 ago
  Here 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 ago
      Probably 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
      - ibraheemdev 6y ago
        Yup, that is what I was referring to.
    - deleted 6y ago
      [deleted]
octoberfranklin 6y ago
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.
- deleted 6y ago
  [deleted]

mmastrac 6y ago

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. [1] https://github.com/mmastrac/stylus/ https://github.com/mmastrac/stylus/

aliceryhl 6y ago
Warp should be out pretty soon. It was mainly waiting for hyper, which is already out for 1.0.
- mmastrac 6y ago
  Ah thanks. I researched this a while back and it didn't seem like there was any ETA but perhaps I can just wait for a bit now.

rossmohax 6y ago

Can'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 ago
Here 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 ago
    Probably 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
    - ibraheemdev 6y ago
      Yup, that is what I was referring to.
  - deleted 6y ago
    [deleted]

octoberfranklin 6y ago

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.

deleted 6y ago
[deleted]