Tokio, the async runtime for Rust, hits 1.0

• tokio

  196 24,854 9.5 Rust

  A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...

  

Yes, it is a concern, but Tokio people decided transition can happen without breaking changes hence it does not block 1.0. See https://github.com/tokio-rs/tokio/issues/2716 for details.

• async-std

  19 3,841 5.3 Rust

  Async version of the Rust standard library

  

> There's at least one other popular one of note.

The other popular runtimes are async-std [0] and smol [1].

[0]: https://github.com/async-rs/async-std

[1]: https://github.com/smol-rs/smol

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• smol

  9 3,430 6.8 Rust

  A small and fast async runtime for Rust

  

Found the 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:PRjMyv...

• warp

  66 9,172 6.4 Rust

  A super-easy, composable, web server framework for warp speeds. (by seanmonstar)

Assuming you mean a web framework, the tokio ecosystem includes warp: A super-easy, composable, web server framework for warp speeds. [0]

[0]: https://github.com/seanmonstar/warp

• stylus

  3 121 2.6 Rust

  Lightweight status page for home infrastructure (by mmastrac)

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.

[1] https://github.com/mmastrac/stylus/

• hyper

  97 13,879 9.2 Rust

  An HTTP library for Rust (by hyperium)

  

Can't find async-std feature here: 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.

• async-std-hyper

  1 40 0.0 Rust

  How to run Hyper on async-std

  

Here is an example: 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 `Future`, but it is relatively simple. As @steveklabnik mentioned:

> 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

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

• rio

  7 894 0.0 Rust

  pure rust io_uring library, built on libc, thread & async friendly, misuse resistant (by spacejam)

The author of sled[1], an embedded database in Rust which has a number of promising features, has also written parts of rio[2], an underlying pure Rust io_uring library, which is intended to become the core write path for sled. rio has support for files but also has a demo for TCP (on Linux 5.5 and later) and O_DIRECT.

I tested rio recently as I had a Brilliant but Bad Idea™ involving file access and was pleasantly surprised by the API, as I have been with sled's.

I'm excited for the experimentation in the Rust ecosystem and for such low level crates to handle the complex io_uring tasks (relatively) safely!

[1]: https://github.com/spacejam/sled

[2]: https://github.com/spacejam/rio

• reqwest

  57 9,205 8.9 Rust

  An easy and powerful Rust HTTP Client

I'm hopeful that this leads to some focus on the ergonomics of "waiting for async things from sync code". Lots of "handlers" in the universe have synchronous interfaces, so if you want to implement them you end up needing to poll/wait on async from a regular function. I swear that every time I poke at Rust, I seem to find some way to cut my fingers...

My specific example is writing a fuse handler (now with cberner/fuser formerly zargony/rust-fuse) for GCS/S3. If you want to use make any async requests (like via hyper), you currently have to roll your own poller, like reqwest does in blocking mode [1].

The rust async/.await primer [2] offers the reader the seemingly helpful futures::executor::block_on, but basically no two executors can interact (and for good reason!). As others highlight, the ecosystem seems like it's going to end up standardizing on tokio (and/or some flavor thereof) and that hopefully now that it's 1.0, we can have stable enough deps for a while :).

[1] https://github.com/seanmonstar/reqwest/blob/5ee4fe5ab64a2e3d...

[2] https://rust-lang.github.io/async-book/01_getting_started/04...

• ureq

  7 1,570 8.5 Rust

  A simple, safe HTTP client

Give ureq a try: https://github.com/algesten/ureq

Suggest a related project