The End of async-std: What Rust Developers Need to Know in 2026

The Rust async ecosystem just got a little simpler—and a little smaller.

On August 27, 2025, the RustSec Advisory Database published RUSTSEC-2025-0052: async-std has been officially discontinued. No patches. No maintainer. No future.

If you're building async Rust in 2026, here's what this means for you.

What Died

async-std was one of the three major async runtimes in Rust—alongside Tokio and smol. It pitched itself as "the Rust standard library's async counterpart," with a design that mirrored std conventions.

The discontinuation wasn't a surprise. The crate had been on life support for years. But the official RUSTSEC advisory makes it clear: if you're still using async-std in production, you're on borrowed time.

The advisory recommends smol as the replacement.

What Replaced It

Smol — The Lightweight Choice

smol has been around since 2019, but it's having a moment. It's the runtime async-std should have been:

• Truly small — the entire runtime is a thin wrapper around async-task and async-io
• Fast — competitive with Tokio on I/O-bound workloads
• Flexible — works with any executor, including the global one
• Tokio-compatible — can wrap Tokio's reactor to use tokio-based libraries

use smol::{io, Task};

fn main() {
    smol::block_on(async {
        let reader = io::Reader::open("file.txt").await?;
        let mut buffer = vec![0u8; 1024];
        reader.read(&mut buffer).await?;
    });
}

The key difference from async-std: smol stays out of your way. It doesn't force a particular executor or runtime model. You can use it as a thin async I/O layer, or plug in your own executor.

Tokio — The Enterprise Standard

Tokio isn't going anywhere. If anything, it's more dominant now:

• Industry standard — every major Rust web framework (Axum, Actix, Warp)默认 uses Tokio
• Battle-tested — powers Cloudflare Workers, Discord, Dropbox
• Ecosystem — tracing, metrics, deadbolt, tower—all built on Tokio
• Maintenance — active development, regular releases, corporate backing

For most projects, Tokio is still the default choice. The discontinuation of async-std doesn't change that.

The 2026 Landscape

Here's where we landed:

| Runtime | Use Case | Status | |---------|----------|--------| | Tokio | Production web services, databases, RPC | ✅ Dominant | | smol | Lightweight services, embedded, library code | ✅ Rising | | async-std | Legacy code | ⚠️ Dead | | async-std (fork) | ??? | ❓ Unclear |

The interesting question is whether anyone will fork async-std. The ecosystem seems content to consolidate around Tokio and smol.

What You Should Do

1. Audit your dependencies — if you depend on async-std, plan your migration
2. If you need Tokio compatibility — just switch to Tokio
3. If you want something lighter — try smol
4. If you're writing a library — use async-fn traits, not runtime-specific ones

The death of async-std is the end of an era—but it's also a simplification. One less runtime to choose between. One less compatibility layer to worry about.

Rust's async story is clearer now. Pick Tokio for production. Pick smol for lightweight work. Move on.

Discuss on Hacker News or Rust's Zulip.