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.
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.
We expect to focus on a few areas this coming year:
integration, and the Tokio stack.
Once the standard library provides the Stream trait, Tokio’s stream utilities will move into the Tokio crate itself.
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.
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
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.
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
ecosystem. This includes work towards new releases of the core
tracing-core crates, adding richer instrumentation to the libraries in the
Tokio stack, and providing integrations with other diagnostics and observability
tools, such as
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.
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.