finds.dev← search

// the find

monoio-rs/monoio

★ 5,019 · Rust · Apache-2.0 · updated May 2026

Rust async runtime based on io-uring.

Monoio is a thread-per-core async runtime for Rust built directly on io_uring (with epoll/kqueue fallbacks), originating from Bytedance. It targets high-throughput network servers where you want to squeeze every syscall out of the kernel without a work-stealing scheduler getting in the way.

io_uring as the primary driver means fewer syscalls and true async I/O without the epoll readiness-then-syscall two-step. Thread-per-core model lets you use thread-local state freely — no Arc/Mutex tax on hot paths. The ownership-based IO abstraction (buffers are moved into ops and returned after completion) is the correct model for io_uring's submit-and-forget semantics, unlike Tokio's readiness model bolted onto uring. monoio-compat exists so you can bridge to the Tokio ecosystem (Hyper, Tower) when you need to, without rewriting everything.

Thread-per-core is a sharp constraint — uneven load distribution across threads is your problem to solve, and the runtime won't help. The IO traits (AsyncReadRent, AsyncWriteRent) are incompatible with Tokio's AsyncRead/AsyncWrite, so most of the ecosystem doesn't work natively; monoio-compat is a workaround with overhead. HTTP and RPC frameworks are listed as 'on the way' and have been for a while — for production HTTP you're still routing through monoio-compat to Hyper, which is awkward. Requires Linux 5.6+ for the main value proposition; anything older falls back to epoll, which makes it no better than alternatives with wider compatibility.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →