Split View: Zig 0.16.0 — I/O를 인터페이스로 만든 릴리스, 그리고 그 청구서

Zig 0.16.0 — The Release That Turned I/O into an Interface, and the Bill It Came With

• Introduction — Eight Months, 1,183 Commits, and a Release That Overhauled the Stdlib
• Passing Io as an Argument — The Path Allocator Already Walked
• How to Read the List of Implementations — What Is Done and What Is Experimental
• What async Promises and What It Does Not
• Cancellation, the Genuinely Hard Part
• "Juicy Main" — main Creates the Io
• Was the Function Coloring Problem Solved — The Release Notes Never Say So
• On the Compiler Side — Incremental Compilation and the New ELF Linker
• Backend Status — x86 Is the Default, aarch64 Has Stalled
• The Upgrade Bill — What Breaks
• So, Should You Use Zig Right Now
• Closing
• References

Introduction — Eight Months, 1,183 Commits, and a Release That Overhauled the Stdlib

Zig 0.16.0 was announced on April 14, 2026. The official announcement is short — eight months of work, 244 contributors, 1,183 commits. (The tarball date listed in the download index is one day earlier, 2026-04-13.) The release notes single out one headline for themselves: "I/O as an Interface."

In one sentence: to borrow the release notes' own wording, starting with Zig 0.16.0, every I/O-capable function must take an Io instance as an argument. Whether you are reading a file, writing to a socket, sleeping, or printing a line to stdout, it is the same rule. The notes also state the criterion for what counts as I/O: broadly, anything that can block control flow or introduce nondeterminism belongs to the I/O interface.

This blog recently covered why Hashimoto is building Ghostty in Zig. There, he said 0.15 changed "the output interface, and everything that outputs anything," and welcomed that breaking change. 0.16.0 is the next chapter of that story, and a much bigger one. This time it is not just output — it is all of I/O.

This post reads the release notes rather than the marketing copy. It follows what actually shipped, what is labeled "experimental," and under what conditions each number was measured. The short version up front: the design is interesting, and the bill is large.

Passing Io as an Argument — The Path Allocator Already Walked

For anyone who has used Zig even a little, this design will feel familiar. Zig has no global allocator. A function that needs memory takes an Allocator as an argument, and the caller decides what actually backs it. A library does not need to know whether it is running on an arena or a GPA.

0.16.0 puts the same logic on I/O. A function that needs I/O takes an Io as an argument. And whether that Io is a thread pool, an event loop, or io_uring is decided by the caller — specifically, by the application's main.

The HTTP example in the release notes shows the ambition of this design well. It looks like ordinary code that sends a HEAD request to one domain.

const std = @import("std");
const Io = std.Io;

pub fn main(init: std.process.Init) !void {
    const gpa = init.gpa;
    const io = init.io;
    const args = try init.minimal.args.toSlice(init.arena.allocator());
    const host_name: Io.net.HostName = try .init(args[1]);

    var http_client: std.http.Client = .{ .allocator = gpa, .io = io };
    defer http_client.deinit();

    var request = try http_client.request(.HEAD, .{
        .scheme = "http",
        .host = .{ .percent_encoded = host_name.bytes },
        .port = 80,
        .path = .{ .percent_encoded = "/" },
    }, .{});
    defer request.deinit();

    try request.sendBodiless();

    var redirect_buffer: [1024]u8 = undefined;
    const response = try request.receiveHead(&redirect_buffer);
    std.log.info("received {d} {s}", .{ response.head.status, response.head.reason });
}

The notes say this code — without a single extra line — has the following properties: it asynchronously sends DNS queries to each configured nameserver, asynchronously attempts a TCP connection to an IP as soon as a response for it arrives, and the instant the first TCP connection succeeds, cancels every other connection attempt in flight, DNS queries included. On Windows, all of this happens without a dependency on ws2_32.dll.

The genuinely interesting sentence comes right after. The notes state that this code also works when compiled with -fsingle-threaded — with the caveat that the operations then happen sequentially. Same source, different execution model, still correct behavior. That is what this design is selling.

How to Read the List of Implementations — What Is Done and What Is Experimental

An interface only matters if it has implementations. And this list is exactly where the hype around 0.16.0 and the reality diverge. Carrying over the notes' own qualifiers:

• Io.Threaded — thread-based. Filesystem operations call read, write, open, and close directly. It is the implementation that gives equivalent behavior when porting code from 0.15.x. In the notes' words it is feature-complete and well-tested, and it supports cancellation too. It is also the implementation "Juicy Main" currently picks.
• Io.Evented — in the notes' own words, a work in progress and experimental, meant to explore where the interface can evolve. Based on userspace stack switching and work-stealing — what people call M:N threading, green threads, or stackful coroutines.
• Io.Uring — the notes state this was not the focus of this release cycle. It is proof-of-concept level, missing networking, error handling, and test coverage.
• Io.Kqueue — proof-of-concept only.
• Io.Dispatch — based on macOS's Grand Central Dispatch.
• Io.failing — simulates a system that supports no operations at all.

Reading this list honestly leads to one conclusion. What 0.16.0 shipped to production is exactly one thread-based I/O implementation, and the thing people get excited about when they talk about this release — Zig async running on io_uring — has not shipped yet. The interface has only built the shape that will eventually hold it.

This distinction is not cynicism. If anything, it is notable that the Zig team wrote it this plainly in their own release notes. Plenty of projects call a proof of concept "support."

What async Promises and What It Does Not

io.async produces a Future(T), where T is the return type of the function called. The semantics the notes describe here are subtle and important.

io.async expresses asynchrony — the fact that this function call is independent of other logic. Because of that, creating this task cannot fail, and it is portable even on top of a restricted Io implementation that has no concurrency mechanism at all. The notes add a remarkably candid sentence here: it is legal for an Io implementation to implement an async call by simply calling the function directly and returning.

That is worth sitting with. io.async is not an instruction to run this concurrently. It is a declaration that this is independent. Whether it actually runs concurrently is up to the implementation. That is exactly why the code still compiles and behaves correctly in a -fsingle-threaded build — it just runs sequentially.

For the cases that genuinely need concurrency, there is a separate io.concurrent. In the notes' words, this conveys that something must run concurrently for correctness. And that inevitably requires a memory allocation — the notes explain this is simply what doing something concurrently entails — so it can fail. That failure is error.ConcurrencyUnavailable.

In other words, Zig splits "things that are allowed to be async" from "things that must be concurrent" into different functions at the type-system level. The former is infinitely portable and cannot fail; the latter demands resources and can fail. Most async runtimes blur this distinction, and personally I think it is the best-designed part of this release.

Future has two methods. await logically blocks control flow until the task finishes and returns the value. cancel behaves like await, except it also asks the implementation to abort the operation and return error.Canceled.

When multiple tasks share a lifetime, there is Group, and the notes state it has O(1) overhead for launching N tasks. Alongside this came Queue(T), Select, Batch, and Clock, Duration, Timestamp, and Timeout, which enforce units through the type system.

Cancellation, the Genuinely Hard Part

Anyone who has built an async runtime knows: the hard part is not launching a task, it is killing one. 0.16.0 spends a fair amount of space on this.

The most impressive implementation detail is this: according to the notes, even Io.Threaded supports cancellation — by signaling the thread so that a blocking system call returns EINTR, and reacting to that error code by checking whether a cancellation was requested before retrying the system call. That is a fairly clever way to implement cancellation in an ordinary thread pool with no event loop and no coroutines.

At the same time, the notes attach an important caveat — requesting a cancellation does not guarantee it will be honored. Cancellation is a request, not a command. Only a request that is honored causes the I/O operation to return error.Canceled.

And the notes lay out three ways to handle error.Canceled, in order of how common they are: propagate it as-is, call io.recancel() to re-arm the cancellation request without propagating it, or make it unreachable with io.swapCancelProtection(). There is also a rule attached: only logic that requested its own cancellation may safely ignore error.Canceled.

The notes also give the pattern for avoiding resource leaks directly.

var foo_future = io.async(foo, .{args});
defer if (foo_future.cancel(io)) |resource| resource.deinit() else |_| {}

var bar_future = io.async(bar, .{args});
defer if (bar_future.cancel(io)) |resource| resource.deinit() else |_| {}

const foo_result = try foo_future.await(io);
const bar_result = try bar_future.await(io);

The notes explain why cancel is mandatory here — it is this call that frees the async task's resources when an error is returned, error.Canceled included. In other words, defer cancel is not there for cancellation itself, it is there for resource reclamation, and that is a landmine anyone new to Zig is bound to step on.

"Juicy Main" — main Creates the Io

If Io is an argument, who creates the first Io? 0.16.0's answer is main.

const std = @import("std");

pub fn main(init: std.process.Init) !void {
    const gpa = init.gpa;
    const io = init.io;

    const ptr = try gpa.create(i32);
    defer gpa.destroy(ptr);

    try std.Io.File.stdout().writeStreamingAll(io, "Hello, world!\n");
}

Attaching a std.process.Init parameter to main brings along things that are already initialized — a process-lifetime arena, a default general-purpose allocator, a default Io implementation chosen for the target configuration, an environment variable map, and preopens for WASI. The notes state that in Debug mode it even sets up leak checking where possible.

The first parameter of main can be one of three things: absent (in which case you cannot access CLI arguments or environment variables), process.Init.Minimal (raw argv and environ only), or process.Init.

The notes also explain why environment variables landed here, and the argument is persuasive. Treating the environment as global state is an extremely common abstraction, but a problematic one — calling something like C's setenv in a threaded context is unsound, because environ is commonly accessed directly with no lock at all. On top of that, the Zig standard library had a real pitfall: std.os.environ was meant to be equivalent to C's environ, but there was no way to populate it in a library that does not link libc.

The notes also show how to hastily create an Io in a place that has none, with an honest warning attached.

var threaded: Io.Threaded = .init_single_threaded;
const io = threaded.io();

The notes say this works as long as you do not need task-level concurrency, but call it not an ideal workaround. The analogy is a good one — it is like reaching for std.heap.page_allocator because you need an Allocator and do not have one. For tests, they recommend using std.testing.io, the way you would use std.testing.allocator.

Was the Function Coloring Problem Solved — The Release Notes Never Say So

The most widely repeated summary going around about this release is that "Zig solved the function coloring problem." So I checked. The word "color" does not appear a single time in the full text of the 0.16.0 release notes.

That sentence has a different source. It is Zig's New Async I/O, written by Zig core team member Loris Cro on July 13, 2025. He builds the claim in three steps there — a single library can behave optimally in both synchronous and asynchronous mode; previously, even if source code was free from the contagion of async/await, the runtime was still forced into stackless coroutines, but now io.async and Future.await can be used with a variety of execution models; and so — in his own words — with this final improvement, Zig has completely defeated the function coloring problem.

A caveat is needed here. That post is from July 2025, discussing the plan at the time, not 0.16.0 itself, and it states outright that a standard library rewrite still remained and only a small part of it landed in 0.15.0. And the plan did in fact change. The stackless coroutines Cro mentions never appear in the 0.16.0 notes even once; what actually shipped as Io.Evented is based on stackful coroutines.

There is a counter-argument too. A post by a writer named ivnj, published the same day, July 13, 2025, argues this: semantically, passing std.Io to every function is no different from making every Node.js function async and returning a promise — Zig has only moved the choice of function color from blocking/non-blocking to io/non-io. A function that does I/O requires a std.Io parameter, and such a function can only be called from another function that itself receives std.Io, so the parameter inevitably propagates through the entire call chain.

My own reading is this. Both arguments are correct, and they are talking about different things. The contagion of color remains — Io propagates up the call chain. What is gone is the rigidity of color. In Rust or JavaScript, a function's color pins down its execution model at compile time. A function that takes Io in Zig does not pin down an execution model — the caller picks it later, and the code stays correct even if the caller picks an implementation with no concurrency at all. And Zig developers have already lived with the fact that Allocator propagates up the call chain in the first place. This is not a new color added on top; it is one more color of the same kind sitting next to a color that was already there.

That said, this is not free. The "Lazy Field Analysis" entry in the notes shows one piece of that cost — a problem discovered after turning I/O into an interface: using std.Io.Writer in any form pulls in std.Io's vtable, and in some cases this led to unnecessary code generation that could bloat binaries. 0.16.0 fixed this by deferring type resolution, but the underlying fact that an interface carries a vtable value with it remains.

On the Compiler Side — Incremental Compilation and the New ELF Linker

I/O took the headline, but the compiler-side changes may be more directly useful in practice.

Incremental compilation improved a great deal this cycle. The notes' example case is striking — when using incremental compilation on the Zig compiler itself, a change that used to recompile nearly the whole compiler now finishes in milliseconds. Credit goes to "Reworked Type Resolution." Overhauling type resolution made the compiler's internal dependency graph acyclic (except in the case of dependency loops), and that eliminated "over-analysis" — rebuilding more code than necessary — in most cases.

The problem of incremental builds emitting a "dependency loop" compile error that non-incremental builds never hit has also been fixed. The notes state this was the single biggest inconsistency between incremental and non-incremental builds in previous releases. The LLVM backend now also supports incremental compilation, with an honest caveat attached — this does not speed up the "LLVM Emit Object" stage. That stage belongs entirely to LLVM, and there is little Zig can do about it. What it does speed up is the process of generating LLVM bitcode on the Zig side, and when there is a compile error — since Emit Object is skipped entirely whenever there is an error — you get near-instant feedback even on the LLVM backend.

And here is the most candid sentence in this release. Incremental compilation still has known bugs, miscompilation included, so it remains off by default even in 0.16.0. But the very next sentence recommends turning it on anyway, noting that users are often surprised by the time it saves. You turn it on with zig build -fincremental --watch.

How should this tension be read? My take: if you only use it for compile-error feedback, the risk is close to zero. Miscompilation is ultimately a problem of generating wrong machine code, and code that fails to compile has no machine code to speak of. On the other hand, if you take the binary an incremental build produced and test or ship it as-is, you can run straight into the miscompilation the notes warn about. "On in the dev loop, clean build for what ships" seems like the reasonable line to draw with this release.

The new ELF linker also landed. Turn it on with -fnew-linker, or with exe.use_new_linker = true in your build script, and it is already the default for the combination of -fincremental and an ELF target. The performance data point the notes give is a scenario where you build the Zig compiler, make a one-line change to a function, and then make another one-line change.

Scenario: build the Zig compiler -> one-line change -> another one-line change

Old linker:            14s, 194ms, 191ms
New linker:             14s,  65ms,  64ms   (66% faster)
Skip linking entirely:  14s,  62ms,  62ms   (68% faster)

What is genuinely interesting in this table is the third row. The new linker is only 3ms away from skipping linking entirely. So the notes say there is not much reason left to expose a -Dno-bin build step — since the compile-speed difference is negligible, it is better to just always leave codegen and linking on, and get an executable out the other end for free.

The cost is clear. The notes explicitly state that this new linker is not feature-complete relative to either the old linker or LLD. The example they give stings — executables built this way have no DWARF info. So both the old linker and LLD are still around, and the plan is to drop the old linker and remove the LLD dependency once the new linker reaches feature parity.

In other words, that 66% figure comes with the condition "if you give up debugging." The 3ms gap tells the same story — a large part of why linking became nearly free is that the linker still is not doing part of the work it used to do.

Backend Status — x86 Is the Default, aarch64 Has Stalled

Self-hosted backend news shows up in every release, but 0.16.0's status needs a clear-eyed look.

The x86 backend got 11 bug fixes this time, and produces better code for constant memcpy. Carrying over the notes' own comparison against the LLVM backend — this backend passes more behavior tests, compiles noticeably faster, has superior debug info, and produces inferior machine code. It remains the default for Debug mode.

These four points explain precisely why it stays Debug-only. In the dev loop, compile speed and debug info are everything and machine code quality barely matters. In a release build, it is exactly the opposite. For reference, the LLVM backend passes 2,004 of 2,010 behavior tests (the notes round this to 100%). The x86 backend passes more than that.

The aarch64 backend is bad news. In the notes' own words — it is still a work in progress, progress on it stalled this release cycle as a side effect of "I/O as an Interface," and running behavior tests against it currently crashes. The notes say they expect progress to pick back up once the standard library settles down.

This shows the opportunity cost of this release plainly. The I/O interface did not come for free — it consumed a cycle of the aarch64 self-hosted backend to get here. For anyone waiting on fast self-hosted compilation on Apple Silicon or ARM servers, 0.16.0 is not progress, it is a pause. The WebAssembly backend passes 1,813 of 1,970 behavior tests (92%).

There is a painful item on the toolchain side too. 0.16.0 moved to LLVM 21.1.0, and in doing so, turned off loop vectorization entirely. The reason is serious — that regression miscompiles the compiler itself in common configurations. The workaround of disabling a specific CPU feature was judged too fragile, so vectorization is off entirely until they move to an LLVM version where the bug is fixed. The notes acknowledge this makes codegen worse in some cases, but say it is still better than miscompilation. And this performance regression is expected to affect not just 0.16.x but 0.17.x too, resolving only in 0.18.x. In other words, upgrading to 0.16.0 means carrying this penalty for two releases.

There is good news too. translate-c switched from a libclang base to an arocc base, removing 5,940 lines of C++ from the compiler source tree (3,763 lines remain). It is one step in the journey of turning a library dependency on LLVM into a process dependency on Clang. Bounds checking for for-loops over slices was improved to generate about 30% less code, and the newly added deflate compression was 9.7% ± 0.2% faster in wall-clock time than zlib at the default compression level (though zlib compresses 1.00% better and, interestingly, executes 18.9% more instructions — a case where fewer cache misses and branch mispredictions won out on time).

The Upgrade Bill — What Breaks

"All I/O takes an Io" is, from an upgrade standpoint, the same sentence as "all code that does I/O is broken."

Start with what got removed. Io.GenericWriter, Io.AnyWriter, Io.null_writer, and Io.CountingReader are gone. SegmentedList, meta.declList, and Thread.Mutex.Recursive are gone too. The formatting API changed — fmt.format became std.Io.Writer.print, Formatter became Alt, FormatOptions became Options, and bufPrintZ became bufPrintSentinel.

Error sets got cleaned up too. error.RenameAcrossMountPoints and error.NotSameFileSystem were merged into error.CrossDevice; error.SharingViolation became error.FileBusy; error.EnvironmentVariableNotFound became error.EnvironmentVariableMissing. DynLib lost Windows support, and the notes' comment on it is funny — users now have to call LoadLibraryExW and GetProcAddress directly, and everyone was probably already doing that anyway.

The language itself moved too. @Type was replaced by individual type-construction builtins; @cImport is moving into the build system (the builtin stays for now, but Aro backs it); runtime vector indexing is now forbidden; and pointers are now forbidden inside packed structs and unions. "Reworked Type Resolution" is, overall, more permissive, but not strictly more permissive — some code that used to compile now hits a dependency loop error.

This brings back the Ghostty story. When Hashimoto said "everything that outputs anything" changed in 0.15, that was not the end, it was the beginning. 0.16.0 overhauled that same family of writers again. The reason he welcomed it — that Andrew Kelley pushes through changes he judges necessary without flinching — holds up again here. And whether you can welcome that attitude is really the test of whether you can use this language at all.

The release notes have a section titled "This Release Contains Bugs." This cycle closed 345 bug reports, but the notes state that Zig still has known bugs, miscompilations, and regressions. And the decisive sentence — doing anything nontrivial with Zig, even on 0.16.x, can require participating in the development process. They add that once 1.0.0 lands, a bug policy will be added as a requirement for Tier 1 support. Read the other way around, that means there is no such policy right now.

So, Should You Use Zig Right Now

Summed up, the decision splits like this.

When it makes sense

• You are building tools or infrastructure code, and your team can absorb the toolchain's breaking changes — an organization where upgrading is routine, not an event.
• You genuinely need an injectable I/O abstraction — the same library running single-threaded in a CLI and on a thread pool on a server. This is the thing 0.16.0 actually delivered.
• Cross-compilation and C interop are core requirements. Zig's strength here holds regardless of the noise around 0.16.0.
• Compile speed is your development-experience bottleneck, and the fast error feedback from -fincremental --watch alone is worth it.

When it is not yet

• You need a stable API. 0.15 changed the writer, 0.16 changed all of I/O. No one is promising what 0.17 changes. Before 1.0, expecting "this is the last big change" in Zig has no basis.
• You need production async I/O running on io_uring right now. What 0.16.0 gave you is a proof of concept — no networking, no error handling, no test coverage yet.
• You need fast self-hosted-backend compilation on aarch64. Progress stalled this cycle, and it currently crashes on behavior tests.
• Machine code quality in release builds is your top priority. The notes themselves say the self-hosted x86 backend produces inferior machine code, and on top of that, LLVM loop vectorization is off until 0.17.x.
• Your team cannot absorb "when you hit a language bug, you participate upstream." That is not my assessment — it is a warning written directly into the release notes.

Closing

What I took away from 0.16.0 is more about design than about the language itself.

Zig's habit of passing Allocator as an argument was never really a story about memory. It was a story about "the caller decides policy, the library only provides the mechanism." 0.16.0 pushed that same principle onto I/O, and along the way split a distinction most async runtimes blur — things that are allowed to be async versus things that must be concurrent — into io.async and io.concurrent. Treating cancellation as a request rather than a command, and implementing cancellation in a thread pool with signals and EINTR, are cut from the same cloth of honesty.

Whether the function coloring problem was "defeated" is, I think, a matter of definition — Io still propagates up the call chain. But given that what propagates is a choice, not an execution model, I think that is a meaningful difference. And the fact that the release notes never declared that victory themselves — that sentence lives on a core team member's personal blog, not in the official notes — only raises my trust in this team.

At the same time, the bill is real. There is exactly one finished implementation, aarch64 has stalled, incremental compilation is off by default because of miscompilation, the new linker cannot produce DWARF, LLVM vectorization is off for two releases, and any code that touches I/O has to be rewritten. The release notes hide none of this — nearly every negative fact in this post, in fact, came straight from the notes themselves.

That is probably the most accurate summary of this release. Zig is still not a "finished product," it is an "argument in progress," and the release notes are the minutes of that argument. If you are willing to sit in on that meeting, 0.16.0 is an interesting release. If you came here to buy a product, read the "This Release Contains Bugs" section at the very bottom of the notes first. That section is not there as boilerplate liability language — it is an accurate statement of where this language actually stands right now.

References

• Zig 0.16.0 Release Notes — the official release notes (source for nearly every fact and number in this post)
• 0.16.0 Released — official announcement (April 14, 2026, 244 contributors, 1,183 commits)
• ziglang.org download index — per-version release dates (0.16.0: 2026-04-13)
• Zig's New Async I/O — Loris Cro, July 13, 2025 (source of "completely defeated function coloring," describing the plan at the time)
• Zig's new I/O: function coloring is inevitable? — ivnj, July 13, 2025 (the counter-argument)
• The founder who went back to the terminal: Hashimoto on Ghostty, Zig, and open source with "no obligation" (related post)