Async crate comparison

Rusts approach to bringing async code into the language is novel, in that instead of packaging the async system with the language, such as Go-langs approach of providing in-built go-routines, 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
Tokio is one of the older libraries still in active development. It's notable for it's large and active user-base. 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
With the primary aim of providing a full runtime API that closely matches the API of Rusts standard library. The original author left the project in early 2020 to work on another runtime, and Yoshua Wuyts is the current lead of the project.

With the primary aim of providing a full runtime API that closely matches the API of Rusts standard library. Originally published in August 2019 by Stjepan Glavina.

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 mio crate.

smol
Though the complexity of runtimes justifies the complexities of a large code-base, smol provides a runtime with a notably small code-base, which can be of particular value in some use-cases. The initial release was authored by Stjepan Glavina, and published in April 2020.

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.