Curriculum/async-vs-threading-rust
Async vs Threading in Rust
scheduling·L2 · idiom·stub
Replacesthe belief that async is always better than threads.
`std::thread` runs OS threads (1 MB stack each, ~10 µs spawn cost, kernel scheduler). `tokio::spawn` runs cooperative tasks on a thread pool (~bytes per task, ~ns spawn cost, userspace scheduler). Async wins for I/O-bound work (10K connections fit in one thread pool); threads win for CPU-bound work (no `.await` points to yield at). The choice is workload-shape, not language-feature.
Prerequisites
Unlocks—
Bridges
- event-loop-vs-thread-poolshared mechanismTokio's runtime is an M:N scheduler: M user tasks multiplexed onto N OS threads. Node.js, Python's asyncio, Go's goroutines all use variants of this pattern. The shared mechanism is cooperative yield points and a userspace task queue.
- io-bound-vs-cpu-boundshared failure modeThe async-vs-threading choice is exactly the io-bound-vs-cpu-bound axis Stage 1's GIL card introduced. The Python/Rust syntax differs; the underlying workload-shape question is identical.
This concept is a node in the curriculum DAG. The full lab — page blocks, done state, references — has not been authored yet. The relations above describe where it sits in the graph.
Author at: content/concepts/async-vs-threading-rust/card.ts