We are pleased to announce the 1.0 release of Tokio, an asynchronous runtime for the Rust programming language. Tokio provides the needed building blocks for writing reliable networking applications without compromising speed. It comes with asynchronous APIs for TCP, UDP, timers, a multi-threaded, work-stealing scheduler, and more.

Over the years, we have been delighted watching our users build amazing things. For example, Discord used Tokio to reduce tail latencies 5x. Fly.io found that, with Tokio, they can effortlessly meet their performance requirements and focus on delivering features to their customers. For the Zcash Foundation, building on Tokio enables them to design misuse-resistant APIs. For AWS, their Lambda team used Tokio to implement more reliable and flexible services.

The tutorial is the best place to learn how to get started with Tokio.

A stability guarantee

We first announced Tokio over four years ago. Since then, it has evolved significantly. The most notable change happened a year ago with the addition of async and await to Rust. Today, Tokio is easier to use and more powerful. This evolution has also caused some friction. It has required libraries to track these changes, and could result in confusing error messages when accidentally depending on multiple versions of Tokio.

The Tokio 1.0 release ends this churn. As part of the release, we are committing to providing a stable foundation for the ecosystem. We have no current plans for Tokio 2.0 and we commit to holding back on a Tokio 2.0 release for at least 3 years. We plan to maintain the Tokio 1.0 branch for a minimum of 5 years. Tokio will keep a rolling MSRV (minimum supported rust version) policy of 6 months. When increasing the MSRV, the new Rust version must have been released at least six months ago.

This stability does not mean Tokio will stagnate. We still have a lot of work to do.

2021

We expect to focus on a few areas this coming year: Stream, io_uring, tracing integration, and the Tokio stack.

Stream

Today, the tokio-stream crate provides asynchronous iteration utilities based on the Stream trait. An RFC to move the Stream trait from futures-core to the Rust standard library is pending approval.

Once the standard library provides the Stream trait, Tokio’s stream utilities will move into the Tokio crate itself.

io_uring

io_uring is a new Linux interface providing asynchronous operations for all types of I/O, including disk, while reducing the required number of syscalls. Currently, on Linux, Tokio uses the epoll(7) interface, which notoriously does not work for disk access. To work around this, Tokio provides asynchronous filesystem APIs by dispatching synchronous operations to a thread pool. While this works, it is not optimal.

By leveraging io_uring, Tokio will be able to provide genuinely asynchronous filesystem operations. Additionally, early benchmarks of io_uring are very promising and we are hopeful that these performance improvements will carry over to Tokio.

tracing

Defining a first-class story around operating Tokio applications will be a focus for 2021. A big part of this story will be tooling around tracing and metrics. The tracing crate already provides much of the needed infrastructure. It implements a facade layer and data model for structured diagnostics, allowing both libraries and applications to emit machine-readable data that can be consumed in a variety of ways.

Over the coming year, we will build deeper integration between tracing and the rest of the Tokio stack. This integration will help provide the needed visibility into Tokio's internals to answer questions. Questions like how you can tune the Tokio runtime to reduce tail latencies, know what tasks are currently running, or which locks are the most contended.

Furthermore, we will continue to improve and grow the rest of the tracing ecosystem. This includes work towards new releases of the core tracing and tracing-core crates, adding richer instrumentation to the libraries in the Tokio stack, and providing integrations with other diagnostics and observability tools, such as tracing-opentelemetry.

The Tokio stack

Tokio provides a runtime and asynchronous APIs for standard primitives such as sockets and timers, but networking applications will often use higher-level protocols such as HTTP and gRPC. The Tokio stack includes Hyper for HTTP and Tonic for gRPC to address these needs. Today, we released Hyper 0.14 with Tokio 1.0 support. Tonic will be updated shortly.

With Tokio 1.0 out the door, we will also focus on Tower, a set of reusable components for building reliable clients and servers.

Thanks

Tokio would not be possible without our many contributors, especially Alice Ryhl, who has been invaluable to the project. Thanks to the leaders of the Tokio stack libraries: Sean McArthur (Hyper), Lucio Franco (Tonic), Eliza Weisman (Tracing), and Thomas De Zeeuw (Mio). Also, Tokio would not have been possible without Aaron Turon's and Alex Crichton's early involvement.

Finally, a big thanks is due to the companies who have financially supported Tokio: Mozilla, Dropbox, Buoyant, and AWS.