Rust async/await vs Go goroutines

WHAT THIS TESTS Whether you understand two fundamentally different concurrency models: Go's runtime-managed green threads versus Rust's poll-based, runtime-agnostic futures, and the ergonomic cost called function coloring.

A GOOD ANSWER COVERS Go bundles an M:N scheduler in its runtime that multiplexes many goroutines onto a few OS threads, with preemption and a growable stack. You write straight-line, blocking-looking code; the runtime handles parking and waking, and channels are the idiomatic communication tool. Rust takes a different path: an async fn compiles to a state machine implementing Future, which is lazy and does nothing until something calls poll. Rust ships no runtime, so you choose an executor such as Tokio or async-std to drive futures, manage the reactor, and handle IO readiness. Function coloring is the consequence that async and synchronous functions are different colors: you can only await inside async, so calling async code tends to force callers to become async too, splitting the ecosystem.

COMMON WRONG ANSWERS Claiming each future is an OS thread, or that futures begin executing when constructed. Saying Tokio is part of std. Treating goroutines as identical to async tasks despite the lazy-versus-eager distinction.

LIKELY FOLLOW-UPS What does .await actually do at the poll level? Why does Rust avoid a default runtime? How do you bridge blocking code into Tokio, for example spawn_blocking? How does cancellation differ, given dropping a future stops it?

ONE CONCRETE EXAMPLE A function fetch returning a future built from two awaits does not start any network IO until you tokio::spawn it or await it inside a runtime. In Go, calling go fetch() immediately schedules the work on the runtime. This eager-versus-lazy contrast captures why Rust needs an explicit executor while Go does not.