finds.dev← search

// the find

async-rs/async-std

★ 4,067 · Rust · Apache-2.0 · updated Aug 2025

Async version of the Rust standard library

async-std was an attempt to mirror the Rust standard library's API surface but with async counterparts — same module layout, same type names, just awaitable. It's officially discontinued; the README tells you to use smol instead.

- The std-mirroring approach was genuinely useful as a learning on-ramp — if you knew std, you knew async-std, which lowered the async Rust barrier meaningfully when it launched

- The stream combinator coverage is thorough: merge, throttle, timeout, double-ended streams, all the iterator analogues — more complete than most async stream libraries at the time

- The book and tutorial (async-chat walkthrough, patterns section on shutdown, fork-join, background tasks) is still decent reference material for async Rust concepts even if you're not using this crate

- It's dead — the maintainers themselves say so in the first line of the README. Any dependency you take on this is a liability you'll eventually have to migrate away from

- The custom executor and threadpool it shipped have been superseded; tokio's runtime is more battle-tested and smol's is lighter — there's no scenario where async-std's runtime is the right choice for new code

- Ecosystem fragmentation was always the real problem here: code written against async-std traits (AsyncRead, AsyncWrite) doesn't compose with tokio traits without async-compat shims, which is exactly the kind of friction it was supposed to eliminate

- The sync primitives (Mutex, Condvar, RwLock) are custom implementations that haven't been maintained — if you're running this in production today you're sitting on unaudited concurrency code

View on GitHub → Homepage ↗

// 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 →