March 13, 2026
Hit snooze, start a flame war
Never Snooze a Future
Rust’s wake‑up call: snoozed code, deadlocks, and a Go vs Rust flamefest
TLDR: A Rust post says “snoozing” — when a task asks to wake but never runs — causes deadlocks and urges safer patterns than select!. Comments exploded into Go-vs-Rust barbs, jokes about snooze buttons, and a blame game over whether the fault lies in Rust, async design, or its libraries.
Rust world just smashed the alarm clock. A new post warns that “snoozing” — when a task asks to be woken up but never actually gets to run — is behind mysterious freezes and “futurelocks” (deadlocks where everything waits forever). The author says snoozing is almost always a bug, and the usual tools that let you juggle many tasks at once can quietly create it. Think of it like a traffic cop who forgets to wave a car through; the whole street looks calm, but one driver never gets the signal. That’s how you get timeouts, hangs, and drama.
The comments? Absolutely lit. One reader went full meme mode: “I thought this was a ‘carpe diem’ motivational post xD.” Then the gloves came off. A top commenter called it a “bug with the async abstraction in Rust,” poking the rival camp: “Goroutines in Go don’t have this.” Another veteran voice dropped a bomb: stop using select! (a pick-one helper used to juggle tasks) and switch to stricter, safer patterns — they’ve been saying it for seven years. Meanwhile, the peanut gallery played blame roulette: is the pain in Rust itself, async design, or the popular libraries? Between sober advice, spicy Go vs Rust jabs, and memes about hitting snooze, the community turned a technical deep dive into a full-on comment cage match. For homework, folks pointed at Tokio docs and Oxide’s “Futurelock” case study for receipts.
Key Points
- •Snoozing in async Rust occurs when a ready future is not polled, leading to hangs, latency, and deadlocks.
- •Snoozing is distinct from cancellation and starvation; the article argues snoozing is a bug while cancellation is not inherently a bug.
- •Deadlocks (“futurelocks”) can occur when a single task polls multiple futures and then stops polling one it started, especially if it holds a resource.
- •A minimal example using tokio::sync::Mutex shows how one future can hold a lock and be snoozed while another is awaited, stalling progress due to inversion of control.
- •Similar risks exist beyond mutexes (e.g., semaphores, bounded channels, OnceCell); understanding poll/Waker mechanics is key to avoiding snoozing.