finds.dev← search

// the find

smol-rs/smol

★ 4,961 · Rust · Apache-2.0 · updated May 2026

A small and fast async runtime for Rust

smol is a lightweight async runtime for Rust that works by re-exporting a constellation of smaller, focused crates (async-executor, async-io, polling, etc.) rather than being a monolith. It's for Rust developers who want async without pulling in all of Tokio, or who want to compose their own runtime from primitives. Compile times are meaningfully faster than Tokio.

The decomposed architecture is the real story — you can use async-executor or async-io independently without taking the whole runtime, which is rare in this ecosystem. The polling crate underneath handles epoll/kqueue/wepoll portably and is solid enough that other projects depend on it directly. The example directory is unusually thorough: TLS, WebSockets, hyper integration, inotify, timerfd — actual working code, not toy snippets. The async-compat bridge for tokio interop is a practical concession to ecosystem reality rather than pretending tokio doesn't exist.

The split-crate model that makes it composable also means you're debugging across 10+ repos when something breaks — tracking down an issue requires knowing whether it lives in polling, async-io, or async-executor. Ecosystem library support still defaults to Tokio; you'll hit friction with any crate that hardcodes tokio::spawn or uses #[tokio::test], and async-compat only patches over some of that. No built-in async runtime attributes (you need smol-macros for that), which is a minor but real ergonomics gap compared to #[tokio::main]. Activity has slowed — last substantive changes feel like maintenance rather than development, which matters if you're betting on this for a production service.

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 →