Zig 0.16.0 released [LWN.net]

The Zig project has announced version 0.16.0 of the Zig programming language.

This release features 8 months of work: changes from 244 different contributors, spread among 1183 commits.

Perhaps most notably, this release debuts I/O as an Interface, but don't sleep on the Language Changes or enhancements to the Compiler, Build System, Linker, Fuzzer, and Toolchain which are also included in this release.

LWN last covered Zig in December 2025.

to post comments

Moving away from LLVM

Posted Apr 15, 2026 9:39 UTC (Wed) by xnacly (subscriber, #182438) [Link] (2 responses)

I think just for the binary size decrease the move away from llvm is a good idea for zig, see the tracking issue:

In exchange, Zig gains these benefits:

All our bugs are belong to us.

The compiler becomes trivial to build from source and to bootstrap with only a C compiler on the host system.

We stop dealing with annoying problems introduced by Linux distributions and package managers such as Homebrew related to LLVM, Clang, and LLD. There have been and continue to be many.

The Zig compiler binary goes from about 150 MiB to 5 MiB.

Compilation speed is increased by orders of magnitude.

We can implement our own optimization passes that push the state of the art of computing forward.

We can attract research projects such as alive2

We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs.

Taken from: make the main zig executable no longer depend on LLVM, LLD, and Clang libraries

Moving away from LLVM

Posted Apr 16, 2026 4:22 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

> All our bugs are belong to us.

Code ZIG! For great justice!

Have the tempfile issues raised in the release notes been fixed?

Posted Apr 20, 2026 16:11 UTC (Mon) by pj (subscriber, #4506) [Link]

The release notes have a minor rant about the kernel's tempfile api, starting out by calling it 'almost good'. :) The complaints boil down to:

1. how openat() indicates that the file system does not support that operation -> It returns either EISDIR or ENOENT, when ENOSYS or OPNOTSUPP or even EINVAL might be more precise choices.

2. linkat() doesn't support the AT_REPLACE flag even though there was a patch for it submitted nearly 10 years ago that was even approved by Linus.

Anyway, here's hoping that one or both of these get fixed.

no memory safety?

Posted Apr 16, 2026 0:41 UTC (Thu) by rolexhamster (guest, #158445) [Link] (3 responses)

From Zig's Wikipedia entry:

Zig requires manual memory management, but attempts to improve memory safety through option types and a unit testing framework.

I'm not sure what's the point of this new-ish language then?

All the other features of Zig are certainly nice-to-haves (just like many parts of C++), but the lack of memory safety a la Rust simply makes Zig a non-starter.

no memory safety?

Posted Apr 16, 2026 11:11 UTC (Thu) by jch (guest, #51929) [Link] (1 responses)

> I'm not sure what's the point of this new-ish language then?

It's an experiment that aims to find out whether it is possible to make a language successful without vastly overselling its benefits.

no memory safety?

Posted Apr 17, 2026 7:08 UTC (Fri) by taladar (subscriber, #68407) [Link]

Which language are you talking about there? Zig certainly doesn't fit that description.

Cross-compile

Posted Apr 21, 2026 3:11 UTC (Tue) by gmatht (subscriber, #58961) [Link]

In my personal experience the point of Zig is to easily cross-compile C-code. Apple has gone out of their way to make it difficult to target the Mac platform, but Zig manages it fine.

I haven't found a use for Zig-the-language, but apparently some people like that it doesn't insert hidden function calls. E.g. in many languages a=b+c might hide a function call in the form of operator overloading, but not Zig.