Rust Async: 7 Common Mistakes That Kill Performance and Cause Crashes

Follow Dream-Beast Programming for a fun way to learn Rust

Ever found yourself scratching your head over a pile of Rust async code? You write async/await with high hopes of silky-smooth, high-performance execution, only to be “pleasantly surprised” by a slow and crash-prone application.

Don’t worry, you’re not alone. Rust’s async world is like a dungeon full of powerful magic and hidden traps. This is especially true for developers coming from languages like JavaScript, Python, or Go. Your old maps are useless here. The patterns you’re used to can be deadly sins in the eyes of Rust.

Today, I’ll be your guide, helping you hunt down the “assassins” lurking in your code to bring your async programs back to life and make them great again!

Mistake 1: Awaiting a Future in a Synchronous Function

Imagine an async function is a recipe detailing “how” to cook a dish (e.g., fetch data from a server). The .await is the chef who actually rolls up their sleeves and “executes” the cooking.

The Deadly Code:

fn main() {
    fetch_data().await; // The assassin is here! The compiler will slap you for this.
}

async fn fetch_data() {
    println!("I'm trying to fetch data...");
}

How It Kills: You can’t just ask the chef (.await) to start working inside a regular synchronous function (like main). That’s like shouting “Start cooking!” from your bedroom; the stove in the kitchen won’t hear you. Rust is principled: The chef (.await) can only work in the kitchen (an async block or function).

The Counter-Strategy: Give the Chef a Kitchen You need an async “runtime,” like the famous tokio or async-std. It creates an entry point for your asynchronous world—a real “kitchen.”

#[tokio::main] // This is like putting a chef's hat on the main function
async fn main() {
    fetch_data().await; // Now this makes sense!
}

async fn fetch_data() {
    println!("Fetching data...");
}

Remember, the #[tokio::main] macro is the key to unlocking the async world.

Mistake 2: Blocking the Async Thread with std::thread::sleep

In the async world, the executor is like a hyperactive courier, constantly juggling hundreds or thousands of packages (tasks) at once.

The Deadly Code:

use std::thread::sleep;
use std::time::Duration;

async fn process() {
    println!("Starting process...");
    // The assassin appears! You're making the hyperactive courier stand still for 5 seconds.
    sleep(Duration::from_secs(5)); 
    println!("Process finished");
}

How It Kills: When you use std::thread::sleep, you’re not just pausing the current “task.” You’re shouting at the entire courier system: “Everyone, halt for 5 seconds!” The courier (the runtime thread) literally stops, and all other packages (tasks) are left waiting. This is called “blocking the thread.”

The Counter-Strategy: Use an Async “Smart Alarm” You need to use the async version of sleep provided by your runtime. It’s like a smart alarm. You tell the courier, “Handle this package in 5 seconds.” The courier sets it aside and continues delivering other urgent packages. After 5 seconds, the alarm goes off, and the courier comes back to it.

use tokio::time::{sleep, Duration}; // Note the import source!

async fn process() {
    println!("Starting process...");
    // This is the correct way to sleep in async.
    sleep(Duration::from_secs(5)).await; 
    println!("Process finished");
}

Core principle: In async code, use async tools. Stay away from std::thread and embrace tokio:: or async_std::.

Mistake 3: Mixing Incompatible Runtimes

Tokio and async-std are both excellent async runtimes, but they are like two powerful, incompatible CEOs.

The Deadly Code (in cargo.toml):

[dependencies]
tokio = { version = "1", features = ["full"] }
async-std = "1.10" # The assassin is watching from the shadows

How It Kills: Inviting both into your project is like appointing two competing heirs to the throne. They will fight over resources (thread pools, task scheduling), leading to bizarre runtime errors, task conflicts, and even outright crashes.

The Counter-Strategy: Be Loyal! Pick One Unless you absolutely know what you’re doing (e.g., writing a library that needs to be compatible with both), please make a choice and stick to it. If you use Tokio, use the Tokio ecosystem from top to bottom. The same goes for async-std.

Mistake 4: Forgetting the JoinHandle Ghost

tokio::spawn is like creating a clone of yourself to handle a sub-task. It’s very cool, but if you don’t manage this clone, it might turn into a ghost.

The Deadly Code:

async fn main_task() {
    tokio::spawn(do_work()); // Launched, and then what?
    println!("Main task finished");
}

async fn do_work() {
    // I might need some time to finish...
    println!("Working hard...");
}

How It Kills: You launched a sub-task with spawn, but the main task main_task doesn’t care if it’s finished and just ends. This can cause the entire program to exit before do_work even has a chance to run, or while it’s halfway through. Your spawned task becomes a kite with a snapped string, its fate unknown.

The Counter-Strategy: Acknowledge It, Wait for It spawn returns something called a JoinHandle, which is like a “controller” for the clone you sent out. You must .await this controller to tell the main task: “Hey, hold on, wait for my clone to finish its work before we proceed.”

async fn main_task() {
    let handle = tokio::spawn(do_work());
    // Wait for the sub-task to complete
    handle.await.unwrap(); 
    println!("Main task is done, after confirming the clone is also done.");
}

If you have multiple sub-tasks, you can use tokio::join! to elegantly wait for all of them to complete.

Mistake 5: The Deadly Temptation of .unwrap()

.unwrap() is a favorite for Rust newcomers and a nightmare for production code. It translates to: “I’m certain there’s a value here. If not, just let the program crash!”

The Deadly Code:

async fn main_task() {
    // Deadly code. If the URL is invalid or the network is down, the whole program panics.
    let res = reqwest::get("http://a-non-existent-url.com").await.unwrap();
}

How It Kills: The async world is full of uncertainty: networks can be flaky, servers can go down, files might not exist. Chaining an .unwrap() after any of these fallible operations is like running naked through a minefield. A small network hiccup is enough to bring your entire service down.

The Counter-Strategy: Gracefully Handle Every Possibility Please, like a mature engineer, use match or the ? operator to handle Result.

async fn main_task() -> Result<(), Box<dyn std::error::Error>> {
    match reqwest::get("http://a-non-existent-url.com").await {
        Ok(res) => println!("Success! Response: {:?}", res),
        Err(e) => eprintln!("An error occurred, but the program is still alive: {}", e),
    }
    Ok(())
}

Remember, in async code, errors are normal. Handle them gracefully, and your program will be rock-solid.

(Note: Mistakes 6 and 7 are variations of 2 and 5, but are more subtle and just as deadly!)

Mistake 6: Using the Wrong Lock and Locking the Universe

When you need to share data between multiple async tasks, you need a lock. But if you use the wrong one, the consequences can be just as devastating.

The Deadly Code:

use std::sync::Mutex; // Assassin: This is a lock from the synchronous world!
use std::sync::Arc;

let data = Arc::new(Mutex::new(0));
// Inside some async fn
let mut d = data.lock().unwrap(); // If this lock is held, other tasks are stuck waiting

How It Kills: std::sync::Mutex is a blocking lock. When an async task acquires this lock but then gets suspended (e.g., due to an .await), it does not release the lock! It holds onto it, forcing any other task that needs the lock to wait, effectively blocking the system again.

The Counter-Strategy: Use the Async “Smart Lock” You must use the Mutex provided by your async runtime.

use tokio::sync::Mutex; // Note the source! This is the async-safe lock.
use std::sync::Arc;

let data = Arc::new(Mutex::new(0));
// Inside some async fn
let mut d = data.lock().await; // Note, this now uses .await!

The .lock() operation on tokio::sync::Mutex is itself an async operation. When a task holding the lock needs to .await something else, the runtime is smart enough to yield CPU time to other tasks instead of selfishly holding onto the resource.

Mistake 7: The Ignored .await

This is the most subtle and often most frustrating assassin. You’ve written the async code, but you forgot the most important part: .await.

The Deadly Code:

use std::time::Duration;

async fn run() {
    // This creates a "future" plan to sleep for 3 seconds, but doesn't execute it.
    tokio::time::sleep(Duration::from_secs(3)); 
    println!("Did I finish sleeping? No, I never even started!");
}

How It Kills: Calling an async function (like tokio::time::sleep) doesn’t execute it immediately. It only returns a Future object, which is merely a “plan.” You must use .await to tell the runtime, “Hey, execute this plan!” If you forget .await, the plan is simply dropped, and nothing happens. The program will instantly print the message, leaving you completely baffled.

The Counter-Strategy: Always Be Vigilant For any function call that returns a Future, ask yourself: “Did I forget to .await?” Luckily, the compiler will often warn you about this, but developing this vigilance yourself is crucial.

Summary: Becoming an Async Master

Alright, all seven “assassins” have been exposed. Let’s put them on a most-wanted poster:

Mastering Rust’s asynchronous programming is all about learning to “think asynchronously.” Forget the habits from the synchronous world and embrace the model of Futures and runtime schedulers. When you can naturally dodge these “assassins,” you’re well on your way to becoming an async master.