Async crate comparison

Rust's approach to bringing async code into the language is novel, in that instead of packaging the async system with the language, such as Golang's approach of providing in-built goroutines, it presents an interface to be used by independent crate developers to implement the async runtime for a given process. Out of this interface, a number of projects have emerged. These projects vary in many ways. Some are are intended to be applied to a narrow use-case in which they particularly excel. Those that are more general purpose often place an emphasis on particular traits such as API design, or performance considerations.

Design considerations
Given that the standard library provides no tools for executing asynchronous code, an independent library is required. Such a library is often called an executor or runtime. It's also not uncommon for a runtime to be used to manage IO and timer functionality as wall - the nature of their non-deterministic order of executions present similar challenges that some runtimes are well-equiped for. This comes with various advantages and disadvantages (TODO: Brief overview of the engineering scope that this coupling benefits, this could probably be improved).

MIO
TODO: Explain how mio fits into the async landscape, such as that it's used under the hood of a number of runtimes for async IO

Tokio
The oldest and most widely used asynchronous runtime still in development, surpassing all other runtimes in usage combined. Created in 2016 by Carl Lerche, who is also the author of mio.

Key design elements

 * Tokio provides many utilities for working with asynchronous code. This includes IO and timer utilities, which are tied to the Tokio runtime.
 * IO is based on the mio crate.
 * Supports several schedulers, configurable by user. Runtime is started manually by user with a function or #[tokio::main] macro.

Actix
Actor system created in 2017 with a focus on type-safe actor model and extensibility. It forms the basis of the web back-end framework actix-web. Uses Tokio under the hood.

embrio
Runtime intended for embedded systems, developed by Wim Looman since 2018.

Bastion
Bastion pivots towards supervision and fault tolerance in the spirit of Erlang. Conceived in July 2019 by Mahmut Bulut.

async-std
Originally published in August 2019 by Stjepan Glavina, with the aim of developing a full runtime whose API is closer to Rust’s standard library than Tokio’s is. The original author left the project in early 2020 to work on another runtime, and Yoshua Wuyts is the current lead of the project.

async-std is the second most widely used runtime.

Key design elements

 * async-std provides a single global runtime, which is started on first use.
 * async-std provides many utilities for working with asynchronous code. This includes IO and timer utilities, which are tied to the async-std runtime.
 * IO is based on the smol crate.

smol
Stjepan Glavina’s second runtime, released in April 2020. One of its core selling points is the small size of the source code, with much of the complexity abstracted into async-task.

Key design elements

 * Provides one global and per-thread runtimes without customization that are started on first use.
 * Includes I/O and a limited set of timer utilities.
 * Uses epoll directly for I/O on Linux, kqueue on macOS/iOS/BSD and the wepoll C library on Windows.

futures-rs
Originally the foundational async crate with Future trait definition and other required types, most important part of which have since been moved into Rust standard library.

Currently notable for the Stream trait and one of AsyncRead and AsyncWrite trait variants. Counterparts for all other utilities are usually included as part of other runtimes.

rotor
The oldest asynchronous runtime ever developed for Rust which included its own vision of Future trait. Eventually deprecated by the currently dominant tokio stack.