Lobsters - 02 Oct 2026
Page 1 of 4
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Zig development is funded via Zig Software Foundation, a 501(c)(3) non-profit organization. Please consider a recurring donation so that we can offer more billable hours to our core team members. This is the most straightforward way to accelerate the project along the Roadmap to 1.0. If you need donation receipts or are looking to migrate away from GitHub Sponsors, we recommend donating via Every.org.
This release features 5 months of work: changes from 206 different contributors, spread among 925 commits.
Originally predicted to be shorter, this release cycle ended up substantial, with the Build System reworked, including the introduction of the Build Server Protocol, and the ELF Linker enhanced to the point where we expect Incremental Compilation to work for everyone on x86_64-linux.
Zig supports a wide range of architectures and operating systems. The Support Table and Additional Platforms sections cover the targets that Zig can build programs for, while the zig-bootstrap README covers the targets that the Zig Compiler itself can be easily cross-compiled to run on.
Notable changes:
- aarch64-openbsd is now tested natively in Zig's CI, ensuring high-quality
support going forward.
- aarch64-freebsd and aarch64-netbsd CI jobs now run on pull
requests too, in addition to master pushes.
- An LLVM bug that broke
most aarch64-windows binaries, including the Zig Compiler, has been
worked around.
- The Zig Compiler now applies mandatory code hardening techniques when targeting
aarch64-openbsd so that the resulting binaries actually work.
- Zig now provides stack traces on crashes and failed assertions on 32-bit ARM. Some work still remains for Thumb-only targets.
- Zig now provides stack traces on crashes and failed assertions on SPARC.
- Zig now handles pointer authentication opcodes when doing stack unwinding on AArch64.
- Support for the loongarch32-linux-gnu[sf] targets has been added.
- Zig now has generally usable support for 64-bit SPARC, and especially
sparc64-linux. This is largely thanks to Zig's new ELF linker which now has better
support for this target than LLD.
- The Zig Standard Library has been ported to the x32 and N32 ABIs on x86-64 and 64-bit MIPS, respectively. These are niche ILP32 ABIs that allow using the 64-bit instruction set while only having 32-bit pointers - the idea being to trade available address space for lower memory usage and better cache utilization.
- Target information has been added for some game consoles: aarch64-switch, arm-gba, mipsel-psx, and powerpc-wiiu
- Very early xtensa-linux support has been added to Zig. Note that, for now,
this support can only be exercised via the C backend or the experimental LLVM
backend.
- The Zig Standard Library now has support for arc[eb]-linux, csky-linux, and m88k-openbsd when using the C backend.
- The Zig Standard Library now has support for no-libc microblaze[el]-linux, sh[eb]-linux, and sparc-linux.
- Zig now enforces -mabi=ieeelongdouble for all PowerPC targets. This is just a
formalization of what was already reality; Zig has never supported the IBM "double-double"
format for long double and likely never will. As a result, this release drops
support for powerpc-linux-gnueabi[hf] because glibc only supports the "double-double"
format on these targets. The powerpc-linux-musleabi[hf] targets remain supported as
they use the IEEE format.
- This release drops support for powerpc64-linux-gnu. Zig has only ever
supported linking ELFv2 binaries for 64-bit PowerPC, and glibc does not officially support
ELFv2 on big endian - nor IEEE long double, as above.
- Zig's ability to detect the native CPU model and features has been greatly enhanced across the board; this affects almost every architecture on every supported OS.
-
The baseline CPU model has been changed for some targets:
- aarch64-haiku: cortex_a55
- m68k-*: M68030
- mips64-openbsd: octeon
- powerpc-netbsd: 750
- powerpc64-freebsd: pwr8
- powerpc64-linux: pwr8
- powerpc64-openbsd: pwr9
- s390x-*: arch11
- sparc-*: generic
- sparc-linux: v9
- sparc64-*: ultrasparc
- xtensa-*: esp32
- In Zig's target query syntax, native libc version detection now only happens if the triple actually uses native libc (i.e. the ABI component is omitted). We expect this new behavior to better match people's mental model for how target queries work, particularly when considering how the OS component works.
Zig's level of support for various targets is broadly categorized into four tiers with Tier 1 being the highest. The goal is for Tier 1 targets to have zero disabled tests - this will become a requirement for post-1.0.0 Zig releases.
- All non-experimental language features are known to work correctly.
- The Compiler can generate machine code for this target without relying on LLVM.
- The integrated fuzzer works on this target (if applicable).
- The Standard Library cross-platform abstractions have implementations for this target.
- Failed assertions and crashes produce stack traces on this target.
- libc is available for this target even when cross-compiling (if applicable).
- Continuous integration machines build the module tests for this target on every push.
- The Compiler can generate machine code for this target by relying on an external backend such as LLVM.
- The Linker can produce object files, libraries, and executables for this target.
- The Compiler can generate assembly or C source code for this target.
In the following table, indicates full support, indicates no support, and indicates that there is partial support, e.g. only for some sub-targets, or with some notable known issues. indicates that the status is largely unknown, typically because the target is rarely exercised. Hover over other icons for details.
Targets marked with are obsolescent; the Zig compiler and standard library maintain best-effort support for them, but that support is expected to be removed eventually.
| Tier | Target | Code Gen. | Linker | Lang. Feat. | Std. Lib. | Stack Traces | Fuzzer | libc | CI |
|---|---|---|---|---|---|---|---|---|---|
| 1 | x86_64-linux | | | | | | | | |
| | | | | | | | | | |
| 2 | aarch64-freebsd | | | | | | | | |
| 2 | aarch64[_be]-linux | | | | | | | | |
| 2 | aarch64-maccatalyst | | | | | | | | |
| 2 | aarch64-macos | | | | | | | | |
| 2 | aarch64[_be]-netbsd | | | | | | | | |
| 2 | aarch64-openbsd | | | | | | | | |
| 2 | aarch64-windows | | | | | | | | |
| 2 | arm-freebsd | | | | | | | | |
| 2 | arm[eb]-linux | | | | | | | | |
| 2 | arm[eb]-netbsd | | | | | | | | |
| 2 | arm-openbsd | | | | | | | | |
| 2 | hexagon-linux | | | | | | | | |
| 2 | loongarch32-linux | | | | | | | | |
| 2 | loongarch64-linux | | | | | | | | |
| 2 | mips[el]-linux | | | | | | | | |
| 2 | mips[el]-netbsd | | | | | | | | |
| 2 | mips64[el]-linux | | | | | | | | |
| 2 | mips64[el]-openbsd | | | | | | | | |
| 2 | powerpc-linux | | | | | | | | |
| 2 | powerpc-netbsd | | | | | | | | |
| 2 | powerpc-openbsd | | | | | | | | |
| 2 | powerpc64[le]-freebsd | | | | | | | | |
| 2 | powerpc64[le]-linux | | | | | | | | |
| 2 | powerpc64-openbsd | | | | | | | | |
| 2 | riscv32-linux | | | | | | | | |
| 2 | riscv32-netbsd | | | | | | | | |
| 2 | riscv64-freebsd | | | | | | | | |
| 2 | riscv64-linux | | | | | | | | |
| 2 | riscv64-netbsd | | | | | | | | |
| 2 | riscv64-openbsd | | | | | | | | |
| 2 | s390x-linux | | | | | | | | |
| 2 | sparc64-linux | | | | | | | | |
| 2 | thumb[eb]-linux | | | | | | | | |
| 2 | wasm32-wasi | | | | | | | | |
| 2 | x86-linux | | | | | | | | |
| 2 | x86-netbsd | | | | | | | | |
| 2 | x86-openbsd | | | | | | | | |
| 2 | x86-windows | | | | | | | | |
| 2 | x86_64-freebsd | | | | | | | | |
| 2 | x86_64-maccatalyst | | | | | | | | |
| 2 | x86_64-macos | | | | | | | | |
| 2 | x86_64-netbsd | | | | | | | | |
| 2 | x86_64-openbsd | | | | | | | | |
| 2 | x86_64-windows | | | | | | | | |
| | | | | | | | | | |
| 3 | aarch64-haiku | | | | | | | | |
| 3 | aarch64-ios | | | | | | | | |
| 3 | aarch64-serenity | | | | | | | | |
| 3 | aarch64-tvos | | | | | | | | |
| 3 | aarch64-visionos | | | | | | | | |
| 3 | aarch64-watchos | | | | | | | | |
| 3 | arm-haiku | | | | | | | | |
| 3 | mips64[el]-netbsd | | | | | | | | |
| 3 | riscv64-haiku | | | | | | | | |
| 3 | riscv64-serenity | | | | | | | | |
| 3 | thumb-windows | | | | | | | | |
| 3 | wasm64-wasi | | | | | | | | |
| 3 | x86-freebsd | | | | | | | | |
| 3 | x86-haiku | | | | | | | | |
| 3 | x86-illumos | | | | | | | | |
| 3 | x86_64-dragonfly | | | | | | | | |
| 3 | x86_64-haiku | | | | | | | | |
| 3 | x86_64-illumos | | | | | | | | |
| 3 | x86_64-serenity | | | | | | | | |
| | | | | | | | | | |
| 4 | alpha-linux | | | | | | | | |
| 4 | alpha-netbsd | | | | | | | | |
| 4 | alpha-openbsd | | | | | | | | |
| 4 | arc[eb]-linux | | | | | | | | |
| 4 | csky-linux | | | | | | | | |
| 4 | hppa-linux | | | | | | | | |
| 4 | hppa-netbsd | | | | | | | | |
| 4 | hppa-openbsd | | | | | | | | |
| 4 | hppa64-linux | | | | | | | | |
| 4 | m68k-linux | | | | | | | | |
| 4 | m68k-netbsd | | | | | | | | |
| 4 | m88k-openbsd | | | | | | | | |
| 4 | microblaze[el]-linux | | | | | | | | |
| 4 | or1k-linux | | | | | | | | |
| 4 | sh[eb]-linux | | | | | | | | |
| 4 | sh[eb]-netbsd | | | | | | | | |
| 4 | sh-openbsd | | | | | | | | |
| 4 | sparc-linux | | | | | | | | |
| 4 | sparc-netbsd | | | | | | | | |
| 4 | sparc64-netbsd | | | | | | | | |
| 4 | sparc64-openbsd | | | | | | | | |
| 4 | xtensa[eb]-linux | | | | | | | | |
The Zig standard library has minimum version requirements for some supported operating systems, which in turn affect the Zig compiler itself:
| OS | Version |
|---|---|
| Darwin | 15.0+ |
| DragonFly BSD | 6.4+ |
| FreeBSD | 14.0+ |
| Linux | 5.10+ |
| NetBSD | 10.1+ |
| OpenBSD | 7.8+ |
| Windows | 10+ |
Zig also has varying levels of support for these targets, for which the tier system does not quite apply:
- aarch64-driverkit
- aarch64[_be]-freestanding
- aarch64-fuchsia
- aarch64-hurd
- aarch64-switch
- aarch64-uefi
- alpha-freestanding
- amdgcn-amdhsa
- amdgcn-amdpal
- amdgcn-mesa3d
- arc[eb]-freestanding
- arm[eb]-freestanding
- arm-3ds
- arm-fuchsia
- arm-gba
- arm-uefi
- arm-vita
- avr-freestanding
- bpf(eb,el)-freestanding
- csky-freestanding
- ez80-freestanding
- ez80-tios
- hexagon-freestanding
- hppa[64]-freestanding
- kalimba-freestanding
- kvx-freestanding
- lanai-freestanding
- loongarch(32,64)-freestanding
- loongarch(32,64)-uefi
- m68k-freestanding
- m88k-freestanding
- microblaze[el]-freestanding
- mips[64][el]-freestanding
- mipsel-psx
- mipsel-psp
- msp430-freestanding
- nvptx[64]-cuda
- nvptx[64]-nvcl
- or1k-freestanding
- powerpc-wiiu
- powerpc[64][le]-freestanding
- powerpc64-ps3
- propeller-freestanding
- riscv(32,64)[be]-freestanding
- riscv(32,64)-uefi
- riscv64-fuchsia
- riscv64-hurd
- s390x-freestanding
- sh[eb]-freestanding
- sparc[64]-freestanding
- spirv(32,64)-opencl
- spirv(32,64)-opengl
- spirv(32,64)-vulkan
- spork8-freestanding
- thumb[eb]-freestanding
- thumb-fuchsia
- thumb-gba
- thumb-vita
- ve-freestanding
- wasm(32,64)-emscripten
- wasm(32,64)-freestanding
- x86[_16,_64]-freestanding
- x86[_64]-hurd
- x86[_64]-uefi
- x86_64-driverkit
- x86_64-fuchsia
- x86_64-plan9
- x86_64-ps4
- x86_64-ps5
- xcore-freestanding
- xtensa[eb]-freestanding
Since the release of Zig 0.16.0, a lot of progress has been made towards stabilizing the language. This is a key step in our roadmap, and a requirement before tagging Zig 1.0.
In particular, since the last release, we have discussed and made decisions on many language proposals - accepting around 25 and rejecting around 125. At the time of writing, 23 undecided language proposals remain open on the Codeberg issue tracker, and 61 undecided language proposals remain open on the legacy GitHub issue tracker. Therefore, this effort represents a significant step towards finalizing the language design (although some major decisions remain).
@bitCast changes
Zig 0.17.0 changes the definition of the @bitCast builtin.
In many cases, the new behavior is equivalent to the old: in particular, casting between an integer type and another integer type is unaffected, as is casting between an integer type and a packed struct or packed union.
However, the semantics of @bitCast calls involving array or vector types have changed. Unfortunately, this change has the potential to break existing code without triggering a compile error.. Therefore, it may be useful when upgrading to audit any @bitCast uses which involve array or vector types.
The new definition of @bitCast is that it reinterprets the logical bit representation of a value as a different type. The following types are considered to have logical bit representations:
- void
- bool
- integer types, except for comptime_int
- floating-point types, except for comptime_float
- integer-backed types enum(T), packed struct(T), and packed union(T)
- arrays or vectors of any of these types
For integer and floating-point types, the logical bit representation starts with the least-significant bit and ends with the most-significant bit. For array and vector types, all elements' logical bit representations are concatenated in order starting with the first element.
In practice, this means that the new @bitCast definition largely aligns with the old behavior on little-endian targets. Unlike the old behavior, the new behavior is fully endian-agnostic, i.e. the operation behaves the same regardless of the target endian.
The new @bitCast definition disallows casts between some types which were previously allowed. In particular, casts involving extern struct or extern union types are no longer permitted. In most cases, code which was using such casts is aiming to reinterpret the value's in-memory representation (sometimes called "type punning") - to achieve this, use @ptrCast or an extern union.
Zig's formal grammar.peg and the actual language implementation did not agree in many places. Probably, the formal grammar has never actually 100% matched the actual handwritten tokenizer and parser.
This problem is now fixed and unblocks future grammar changes and language specification work.
At a high level, the approach was to write a tool that accepts Zig's grammar.peg as input and outputs a
simple recursive descent parser. This generated parser is then used as an oracle for fuzz testing and the
handwritten std.zig.Ast.parse() is compared against it. This approach ensures a
single source of truth and allows for easy iteration as the grammar changes.
More details: #36094
@cImport
was deprecated in Zig 0.16.0 and is now removed. Furthermore, in this release
std.Build.Step.TranslateC is deprecated in favor of an explicit package dependency on
official ZSF translate-c package, which is the same
implementation the build step provides, but offers
more configuration options for the
translated code, and has an independent release cadence from the main Zig toolchain.
Upgrade guide:
zig fetch --save git+https://codeberg.org/ziglang/translate-c--- a/build.zig
+++ b/build.zig
@@ -1,16 +1,19 @@
const std = @import("std");
+const Translator = @import("translate_c").Translator;
pub fn build(b: *std.Build) void {
const target = b.standardTargetOptions(.{});
const optimize = b.standardOptimizeOption(.{});
- const translate_c = b.addTranslateC(.{
- .root_source_file = b.path("src/c.h"),
+ const translate_c = b.dependency("translate_c", .{});
+
+ const translator: Translator = .init(translate_c, .{
+ .c_source_file = b.path("src/c.h"),
.target = target,
.optimize = optimize,
+ // additional options now available that go here:
+ // https://codeberg.org/ziglang/translate-c#options
});
- translate_c.linkSystemLibrary("glfw", .{});
- translate_c.linkSystemLibrary("epoxy", .{});
+ translator.linkSystemLibrary("glfw3", .{});
+ translator.linkSystemLibrary("epoxy", .{});
const exe = b.addExecutable(.{
.name = "tetris",
@@ -21,7 +24,7 @@ pub fn build(b: *std.Build) void {
.imports = &.{
.{
.name = "c",
- .module = translate_c.createModule(),
+ .module = translator.mod,
},
},
}),
@backingInt and @fromBackingInt
The @backingInt and @fromBackingInt builtins are new.
These builtins replace the now-deprecated @intFromEnum and
@enumFromInt builtins (#35966).
@backingInt works with all enums and with bitpacks with explicit backing
integer types only. It also works with tagged unions, returning the backing
integer of the active tag value.
An undefined enum or bitpack yields an undefined backing integer.
@fromBackingInt infers its result type, which may be any enum or a bitpack with an
explicit backing integer type. It takes a parameter of exactly that backing integer type. For enums,
passing a backing integer that is either undefined or would yield an invalid tag
value results in safety-checked Illegal Behavior. For bitpacks, passing an undefined
Next page | More Lobsters | Headlines
Original: https://ziglang.org/download/0.17.0/release-notes.html