Metal I/O library for Rust.
7k
Stars
846
Forks
22
Open issues
30
Contributors
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.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
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.
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.
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.
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.
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.
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.
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.
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
- 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.
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.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Rust
- License
- MIT
- Last updated
- 24h ago
- Created
- 145mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Windows: re-arm on a read WouldBlock produces a spurious writable event
NamedPipe permanently leaks HANDLEs
Address WASIp2 TODOs once `wasi-libc` and `wasmtime-wasi` patches land in stable releases
QNX: Add ionotify()‑based event driver (avoid poll() fallback)
Reenable AIX in CI
Top contributors
Similar repos
Totodore/socketioxide
Socketioxide is a Socket.IO server implementation in Rust that integrates with...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
7k | +5 | Rust | 8/10 | 24h ago |
|
|
1.7k | — | Rust | 8/10 | 6d ago |
|
|
32.5k | — | Rust | 9/10 | 3d ago |
|
|
5k | — | Rust | 8/10 | 1mo ago |
|
|
1.6k | — | Rust | 8/10 | 13h ago |
|
|
2.2k | — | Rust | 8/10 | 2d ago |
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 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.
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.
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 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.