Zig's New Async I/O

General sentiment about Zig and the talk

• Many commenters praise the talk and Zig’s design culture, noting lots of ideas have been tried and discarded, with emphasis on features that compose well.
• Some are returning C users asking whether Zig’s benefits (stdlib, comptime, build system, C interop) justify the churn before 1.0; answers highlight expressiveness and tooling, but acknowledge stdlib instability and design inconsistencies.

Async vs threads and function coloring

• Several replies stress that async and threads are orthogonal: you can have async with or without threads, and vice versa.
• There’s disagreement on async’s value: some dislike async/await “polluting” code and making reasoning about time and state harder; others argue this “pollution” is a useful, explicit signal of non‑blocking behavior.
• Function coloring is seen as a real ecosystem issue in Rust/JS; some hope Zig avoids a split between blocking and async APIs.

Zig’s new async I/O design

• The new model passes an io object (similar to how allocators are passed) and provides io.async / await as ordinary functions, not special syntax.
• Different Io implementations are intended: a thread‑pool variant (already demoed), plus future stackless and stackful coroutine backends.
• Asynchrony is decoupled from concurrency: the same code can run synchronously or concurrently, depending on the io implementation. If concurrency isn’t available, operations may fail with a specific error.
• Cancellation is cooperative: cancel requests propagate through IO operations (which return a Canceled error), with optional explicit polling for long CPU tasks.

Critiques and conceptual worries

• Some find the Io abstraction “OO‑like” and fear it hides function coloring: any function taking io is now potentially blocking or async, making local reasoning harder and creating coupling across library boundaries.
• Others argue this is no worse than allocators or IO in other languages, and that tests against standard Io variants define the contract.
• A few see this as an ad‑hoc effect system; they worry about complexity, cancellation semantics (e.g., getting a result both in await and cancel), and possible violations of “no hidden control flow” in spirit.
• There is unease about Zig’s overall direction (simple vs complex, low‑ vs high‑level), and whether async belongs in the core stdlib rather than a separate package.

Comparisons to other ecosystems

• Rust async is criticized as complex (executors, futures forms, missing stable generators) compared to JS promises; others respond that Rust tackles more general problems and different tradeoffs.
• Java/.NET virtual threads and structured concurrency are cited as attractive “single paradigm” approaches; counter‑arguments note performance tradeoffs vs low‑level languages.
• BEAM/Elixir are mentioned as an ideal concurrency model, but seen as requiring very different runtime assumptions.