tokio-rs

tokio-rs/mio

Rust MIT Dev Tools

Metal I/O library for Rust.

7k stars
846 forks
active
GitHub +5 / week

7k

Stars

846

Forks

22

Open issues

30

Contributors

v0.8.0 13 Nov 2021

AI Analysis

Mio is a low-level, non-blocking I/O library for Rust that provides minimal-overhead abstractions over OS-level event notification systems (epoll, kqueue, IOCP). It is purpose-built for developers constructing high-performance networked applications and event-driven systems who need fine-grained control over I/O multiplexing; it is not a general-purpose async runtime and explicitly directs users seeking ease-of-use to higher-level libraries like Tokio.

Dev Tools Library Discovery value: 2/10
Documentation 8/10
Activity 9/10
Community 8/10
Code quality 8/10

Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.

Overall score 8/10

AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.

event-driven-io non-blocking-networking rust-systems async-primitives os-abstraction
Actively maintained Well documented MIT licensed Niche/specialized use case Production ready
Deep Analysis · Based on README and public signals
2w ago

Mio: The low-level non-blocking I/O foundation underpinning most of Rust's async ecosystem

Mio is a thin, cross-platform wrapper around OS-level I/O event notification mechanisms (epoll, kqueue, IOCP), providing non-blocking sockets and an event polling loop with near-zero runtime overhead. It is primarily built for authors of async runtimes and high-performance networking libraries in Rust — not for application developers directly. Tokio, the dominant Rust async runtime, is built on top of Mio, making Mio an invisible but critical dependency across a large fraction of the Rust networking ecosystem.

Origin

Started in August 2014 by Carl Lerche, Mio was one of the earliest serious attempts to bring epoll/kqueue-style event-driven I/O to Rust. It predates the async/await language feature and served as the foundational layer around which Tokio was later constructed.

Growth

Mio's star growth is slow and effectively flat today (4 stars in the last 7 days) because it is infrastructure: most users encounter it only as a transitive dependency of Tokio. Its adoption grew in lockstep with the Tokio ecosystem explosion from 2019 onward. The v1.0 release stabilized the API and signaled long-term commitment to backward compatibility.

In production

Mio is a direct dependency of tokio (32k+ stars, used by a large portion of production Rust services worldwide). It is transitively present in virtually every Rust application using Tokio-based networking. crates.io download counts for mio are in the hundreds of millions, making this one of the most widely deployed Rust crates in existence, primarily as an indirect dependency.

Code analysis
Architecture

Appears to follow a platform-abstraction design: a unified Poll/Registry/Events API on top of OS-specific backends (epoll on Linux/Android, kqueue on BSD/macOS/iOS, IOCP on Windows). Feature flags ('os-poll', 'net') allow selective compilation. Zero-allocation at runtime is a stated design constraint, suggesting likely avoidance of heap allocation in hot paths. Likely a thin safe Rust wrapper with unsafe platform calls underneath.

Tests

Not documented in README, but CI via GitHub Actions is present and active, suggesting automated testing exists. The breadth of supported platforms implies platform-specific CI matrix testing is likely in place.

Maintenance

Last push was 2026-05-28, approximately one month before the evaluation date — indicating active maintenance. The project is under the tokio-rs GitHub organization, which has strong institutional backing. A clear MSRV policy is documented and versioned, reflecting mature release management practices.

Honest verdict

ADOPT IF: you are building an async runtime, a low-level networking library, or need direct, fine-grained control over non-blocking I/O event polling in Rust with minimal overhead. AVOID IF: you are building an application — use Tokio or async-std directly instead; Mio's API requires significant boilerplate and manual event loop management. MONITOR IF: you depend on Tokio and want visibility into stability and platform support changes at the foundational layer.

Independent dimensions

Mainstream potential

3/10

Technical importance

9/10

Adoption evidence

9/10

Risks
  • As infrastructure beneath Tokio, Mio's API evolution is constrained by Tokio's compatibility requirements, potentially slowing adoption of newer OS I/O mechanisms like io-uring.
  • Windows IOCP support via the wepoll strategy may lag behind Linux/macOS in feature parity or performance optimization, as IOCP semantics differ significantly from epoll/kqueue.
  • The explicit non-goals (no file I/O, no thread pools, no timers) mean users building a complete runtime must compose many additional crates, increasing integration complexity.
  • If Tokio were to internalize or replace its Mio dependency with a custom backend (e.g., io-uring on Linux), Mio's relevance could decline without affecting most application developers.
  • MSRV policy ties minor version bumps to Rust version increases, which may create friction for users on toolchains with strict version pinning requirements.
Prediction

Mio is likely to remain stable, well-maintained infrastructure for the foreseeable future. Its role as Tokio's foundation gives it strong longevity, though it may slowly cede ground on Linux to io-uring-based alternatives over a 3-5 year horizon.

0 found this helpful

Newsletter

Get analyses like this every Monday

Free weekly digest of the most interesting open-source discoveries.

Languages

Rust
99.7%
Makefile
0.3%

Information

Language
Rust
License
MIT
Last updated
24h ago
Created
145mo ago
Analyzed with
anthropic/claude-haiku-4-5

Stars over time

Loading…

Contributors over time

Top 100 contributors only — repos with more will plateau at 100.

Loading…

Similar repos

tokio-rs

tokio-rs/io-uring

io-uring is a low-level Rust userspace interface to the Linux io_uring kernel...

1.7k Rust Dev Tools
tokio-rs

tokio-rs/tokio

Tokio is a production-grade async runtime for Rust that provides the core I/O,...

32.5k Rust Dev Tools
monoio-rs

monoio-rs/monoio

Monoio is a Rust async runtime optimized for io-bound server workloads using...

5k Rust Dev Tools
Totodore

Totodore/socketioxide

Socketioxide is a Socket.IO server implementation in Rust that integrates with...

1.6k Rust Web Dev
tokio-rs

tokio-rs/bytes

Bytes is a Rust utility library providing ergonomic abstractions for working...

2.2k Rust Dev Tools
vs. alternatives
tokio-rs/tokio

Tokio is built on top of Mio and is a complementary higher-level runtime, not a direct competitor. Application developers choose Tokio; runtime authors and low-level library authors interact with Mio.

monoio-rs/monoio

Monoio is an io-uring-based async runtime that bypasses Mio entirely, targeting Linux with thread-per-core architecture. It serves a narrower, more specialized use case and is not cross-platform.

polling (smol-rs/polling)

The 'polling' crate serves a similar low-level event notification role and is the foundation for the smol/async-std ecosystem. It competes directly with Mio at the same abstraction level, though Mio has significantly wider ecosystem adoption.

n0-computer/iroh

Iroh is a high-level networking library for peer-to-peer communication built on Tokio. It operates at a much higher abstraction level and depends on the ecosystem Mio underpins.

libuv (C library)

libuv is the analogous cross-platform event loop for C/Node.js. Mio covers similar OS-level abstractions but is Rust-native with no FFI overhead, and has a narrower, more explicit API surface.