Same async/await, seven answers: why languages disagree on concurrency

Brown University researchers set out to test how uniform async/await really is across modern languages, and found far more divergence than expected. Their paper, ‘A Design Space Exploration of Async/Await,’ demonstrates the problem with a trivial program: a function spawns a background log write as a fire-and-forget task, then the caller waits a moment and prints. Run against seven async runtimes, that program yields four distinct outputs — and across three variants of it, no two runtimes produce identical results. The paradigm’s whole selling point, making concurrent code read like straight-line code, hides deep semantic disagreement underneath.

The authors formalize the differences as nine ‘design dimensions’ — decisions that change observable behavior rather than mere performance — grouped by a task’s lifecycle: start of life, end of life, and cancellation. The popular ‘hot vs. cold’ distinction (whether an async call starts running immediately or stays inert until awaited) is just one of them, which they call Eagerness. Two others explain the sample program: Swift and Python’s Trio enforce Dynamic Extent, meaning a spawned task cannot outlive the function that created it, whereas other runtimes let it escape. When the scope ends, Swift cancels the outstanding task (Cancelled Destruction) while Trio waits for it to finish (Awaited Destruction) — which is why Swift prints ‘AC’ and Trio prints ‘ABC.’

To make the space precise, the team encoded these choices into a formal small-step semantics over a core calculus of async programs, letting them trace exactly where two runtimes fork. The practical takeaway is a caution for engineers: there is no correct answer, only trade-offs in ergonomics, memory, and cancellation behavior, and porting concurrent code between languages — or reasoning about it at all — is riskier than the shared keywords suggest.