Did Zig Fix Async / Await?

Zig’s async/await push is built around a key constraint: Zig has no hidden allocations, so “await” can’t quietly create promises, heap stacks, or other runtime machinery the way higher-level languages often do. The emerging solution treats async as part of an explicit IO interface—so the caller supplies both an allocator and an IO implementation, and the async machinery can be tailored without introducing surprise memory costs. The result is a design that aims to keep Zig’s low-level guarantees while still enabling structured concurrency features like cancellation and “select”-style racing.

At the center of the approach is an IO abstraction that represents anything that can block the current thread: not just network and file operations, but also potentially long CPU work. Instead of “awaiting” a generic promise object, Zig code works with an IO object whose methods return a cancellable result (with cancellation represented as an error-like outcome). The design also borrows a Go-like flavor: there’s an “async without await” concept (described as “crippled async”) and explicit cancellation, both intended to be composable rather than magical.

A major theme is that the caller chooses how async executes. In practice, that means selecting an IO implementation—such as one backed by a thread pool or one driven by an event loop—at program startup (alongside choosing an allocator). This “bring your own IO” model lets the same Zig library run across different environments, including custom operating systems, because the library depends on the IO interface rather than a specific OS mechanism. The speaker frames this as analogous to how allocator injection works: the library encodes intent and concurrency structure, while the IO implementation decides the execution strategy.

The transcript also highlights how “hot vs cold” execution maps onto Zig’s async model. Operations that start immediately are treated as “hot/eager,” while others remain “cold/lazy” until the chosen IO implementation triggers them—giving the caller control over when work begins. That control is crucial for predictable resource usage and for enabling parallelism patterns where computations can be launched early and joined later.

Cancellation and select are presented as userland-friendly features enabled by the interface-based design. Cancellation is managed with scoped cleanup (using deferred cancellation so losing a race cancels the other branches). Select is described as “first future to finish wins,” effectively racing multiple async operations while still ensuring resources are cleaned up.

Under the hood, the transcript argues that Zig’s “single compilation unit” strategy is what makes this feasible for interface-driven async. The compiler needs to know the closed set of possible function targets behind function pointers (via restricted function pointer types) to compute upper bounds on stack usage. Without that, parallel execution would require unsafe or overly conservative heap allocation of stacks.

Finally, the discussion acknowledges real-world migration pain: updating Zig’s standard IO reader/writer to fit the new async8 pattern is expected to cause major breakage and require rewriting code that touches those interfaces. Still, the direction is framed as a long-term fix—one that keeps Zig’s explicit memory model while making async/await practical, modular, and portable across execution backends.