Async Rust with Tokio

Reviewed & published by Brayan K

Rust's async/await lets you handle thousands of concurrent operations on just a handful of threads — and Tokio is the runtime that makes it practical for real networking and I/O.

Part of the free Rust course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

In this lesson you'll write async functions, drive them with the Tokio runtime, run tasks concurrently with spawn and join!, and pass messages between tasks with channels.

What You'll Learn in This Lesson

• Writing async fn and the Future they return
• Starting a runtime with #[tokio::main]
• Awaiting work with .await
• Running tasks with tokio::spawn
• Concurrency with tokio::join!
• Message passing with tokio::sync::mpsc

1️⃣ async / await and the Tokio Runtime

An async fn returns a Future — a value that does no work until it is driven. The .await keyword drives a future to completion, yielding control to the runtime while it waits. The #[tokio::main] attribute sets up that runtime and runs your async main.

// Async functions return a Future. They do NOTHING until you .await them.
// #[tokio::main] starts a Tokio runtime and runs this async main for you.
use tokio::time::{sleep, Duration};

async fn greet(name: &str) -> String {
    // sleep is an async pause: it yields to the runtime instead of blocking.
    sleep(Duration::from_millis(50)).await;
    format!("Hello, {name}!")
}

#[tokio::main]
async fn main() {
    // Calling greet(...) builds a future. Awaiting it drives it to completion.
    let message = greet("Tokio").await;
    println!("{message}");
}

Nothing ran until .await. While sleep waited, the runtime was free to do other work instead of blocking the thread.

2️⃣ Concurrency with spawn and join!

tokio::spawn launches an independent task and returns a JoinHandle you can await for its result. tokio::join! runs several futures concurrently on the current task and waits for all of them — overlapping the waits instead of adding them up.

// Concurrency: run many things at once on a small number of threads.
use tokio::time::{sleep, Duration};

async fn fetch(id: u32) -> u32 {
    sleep(Duration::from_millis(100)).await; // pretend this is a network call
    id * 10
}

#[tokio::main]
async fn main() {
    // tokio::spawn schedules a task that runs concurrently. It returns a
    // JoinHandle you can .await to get the task's result.
    let handle = tokio::spawn(async { fetch(1).await });

    // tokio::join! awaits several futures concurrently on THIS task.
    // All three "network calls" overlap, so this takes ~100ms, not ~300ms.
    let (a, b, c) = tokio::join!(fetch(2), fetch(3), fetch(4));

    let spawned = handle.await.unwrap(); // unwrap the JoinHandle result
    println!("spawned = {spawned}");
    println!("joined  = {a}, {b}, {c}");
}

Three 100ms "fetches" finished in about 100ms total because they overlapped. That overlap, not extra threads, is what async concurrency buys you.

3️⃣ Talking Between Tasks with Channels

Tasks share data safely by message passing. tokio::sync::mpsc is a multi-producer, single-consumer channel: many tasks can send, one task recvs. When every sender is dropped, recv() returns None.

// Channels let tasks communicate. mpsc = multi-producer, single-consumer.
use tokio::sync::mpsc;

#[tokio::main]
async fn main() {
    // Create a bounded channel with capacity 8.
    let (tx, mut rx) = mpsc::channel::<i32>(8);

    // A producer task sends values, then drops its sender.
    tokio::spawn(async move {
        for i in 1..=3 {
            tx.send(i).await.unwrap(); // .await: waits if the channel is full
        }
    });

    // The consumer receives until every sender is dropped (recv returns None).
    while let Some(value) = rx.recv().await {
        println!("got {value}");
    }
}

A bounded channel also gives you backpressure: if the buffer is full, send().await waits until there is room, so a fast producer can't overwhelm a slow consumer.

Mini-Challenge: Overlap the Waits

Run three async "downloads" concurrently with tokio::join! so the program finishes in the time of the longest one.

// 🎯 MINI-CHALLENGE: download three things concurrently.
//
// 1. Write an async fn work(ms: u64) -> u64 that sleeps for ms milliseconds
//    (use tokio::time::sleep) and then returns ms.
// 2. In an async main marked with #[tokio::main], use tokio::join! to run
//    work(30), work(20), and work(10) concurrently.
// 3. Print the three results. Because they overlap, the whole program should
//    finish in about 30ms, not 60ms.

#[tokio::main]
async fn main() {
    // your code here
}

Common Errors (and the fix)

• "`await` is only allowed inside `async` functions" — Move the call into an async fn or an async {} block.
• Future created but never awaited — Calling an async fn does nothing; you must .await or tokio::spawn it.
• "future cannot be sent between threads safely" — Data held across an await in a spawned task must be Send and 'static.
• Blocking the runtime — Use async sleeps/locks (tokio::time::sleep), or spawn_blocking for heavy CPU work.

Pro Tips

• 💡 Reach for join! to overlap waits: independent awaits should run concurrently, not one after another.
• 💡 Prefer channels over shared mutable state: message passing avoids many concurrency bugs.
• 💡 Don't block the executor: never call thread-blocking std functions inside async code.

📋 Quick Reference — Async & Tokio

🎉 Lesson Complete!

• ✅ async fn returns a lazy Future driven by .await
• ✅ #[tokio::main] starts the runtime that schedules your tasks
• ✅ tokio::spawn and tokio::join! run work concurrently
• ✅ mpsc channels let tasks communicate with backpressure

Practice quiz

Continue this course

• Previous: Capstone: A CLI Tool
• Next: Web Framework with Axum — Build an HTTP server with Axum — routers, handlers, extractors, and state
• Quick reference: Rust cheat sheet

Frequently asked questions

What is the difference between async tasks and OS threads?

OS threads are scheduled preemptively by the operating system and each carries its own stack, so spawning thousands of them is expensive. Tokio tasks are lightweight futures scheduled cooperatively by the runtime on a small pool of worker threads. A task only gives up its thread at an .await point, which is why async shines for I/O-bound work: a few threads can manage tens of thousands of connections because each task yields while it waits for the network. For CPU-bound work that never awaits, real threads (or tokio::task::spawn_blocking) are usually the better fit.

Why does my async function do nothing when I call it?

Futures in Rust are lazy. Calling an async fn does not run its body — it just builds a Future value that represents the work. The body only makes progress when something polls the future, which happens when you .await it or hand it to the runtime with tokio::spawn. This is different from many languages where calling an async function immediately starts it. If you see a warning like 'unused implementer of Future that must be used', it means you created a future and forgot to await or spawn it.

When should I use tokio::spawn versus tokio::join!?

Use tokio::join! when you want to run a fixed set of futures concurrently on the current task and wait for all of them together — it returns a tuple of their results. Use tokio::spawn when you want a task to run independently in the background, possibly outliving the current scope, and you get back a JoinHandle you can await later (or simply let run). spawn requires its future to be Send and 'static because it can move to another worker thread, while join! has no such requirement.

How do tasks communicate safely?

The idiomatic way is message passing with channels from tokio::sync, such as mpsc (multi-producer, single-consumer), oneshot (a single value), or broadcast. Sending on an mpsc channel is itself async: tx.send(value).await waits if a bounded channel is full, providing natural backpressure. The receiver's rx.recv().await returns Some(value) for each message and None once all senders are dropped. Channels avoid sharing mutable state directly; when you do need shared state, reach for tokio::sync::Mutex or an Arc around your data.