Zig 0.16 shipped on Thursday and completes a project Andrew Kelley started in 2021: the self-hosted compiler backend now handles every officially supported target without LLVM. LLVM remains available as an optional backend for maximum optimization, and it is no longer required to build or use Zig. The compiler binary drops from about 180 megabytes to 12. Debug builds compile roughly 2.4 times faster on the project's own benchmarks. Cross-compilation, already Zig's best feature, now works from a 12 megabyte download that contains everything needed to target sixteen architecture and operating system combinations.
Why removing LLVM was worth years of work
LLVM is an excellent optimizing backend and a heavy dependency. It compiles slowly, it is enormous, its release cadence forces downstream projects to track its API changes, and its debug-build performance is poor because it is architected for optimization. For a language whose pitch includes fast compilation and painless cross-compilation, carrying LLVM undercut both claims.
export async function handler(request: Request): Promise<Response> { const started = Date.now(); const upstream = await fetch(request); const headers = new Headers(upstream.headers); headers.set("x-skarvonix-ms", String(Date.now() - started)); return new Response(upstream.body, { status: upstream.status, headers, });}The self-hosted backend generates machine code directly for each target. For debug builds it skips the intermediate representation optimization passes entirely, which is where most of the speedup comes from. For release builds it applies a smaller set of optimizations than LLVM and produces code that Kelley's own benchmarks put 8 to 15 percent slower on compute-heavy workloads. Anyone needing that last margin selects the LLVM backend with a flag and accepts the compile time.
What this does for cross-compilation
Zig has been quietly used as a C and C++ cross-compiler by projects that have nothing to do with Zig the language, because zig cc bundles libc implementations for many targets and produces working binaries without the toolchain assembly that cross-compiling normally requires. Go projects use it. Rust projects use it. That capability now ships in a 12 megabyte binary, which makes it viable to include in a CI image or a container without thinking about it.
The compiler ships musl, glibc stubs, and the necessary headers for Linux targets, plus the Windows and macOS system interfaces where licensing permits. Targeting an ARM Linux device from a Windows laptop is one flag. That has been true for a few years and the size reduction changes who is willing to adopt it, since a 180 megabyte tool in a build pipeline is a decision and a 12 megabyte one is not.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The rest of the release
The async story remains unresolved, which is the largest open question about the language. Async and await were removed in 0.11 pending a redesign, and the current release includes an experimental implementation behind a flag that uses a stackless approach with explicit io parameters. The design has been discussed publicly for two years and Kelley has been clear that shipping it wrong is worse than shipping it late.
The build system gained incremental compilation that actually works, tracking dependencies at function granularity and rebuilding only what changed. On a large project a single-function change now rebuilds in under 200 milliseconds. The standard library reorganized its allocator interfaces, which is a breaking change and which the release notes document with a migration table.
Zig's actual adoption
The language remains pre-1.0 and breaks compatibility between releases, which keeps it out of most production use. The projects that have adopted it anyway are notable: Bun is written in Zig, TigerBeetle built a financial database on it, and Uber uses zig cc in its C++ build pipeline. Each of those chose it for a specific property, respectively fast compilation, deterministic behavior, and cross-compilation, rather than as a general-purpose language decision.
The Zig Software Foundation operates on donations and corporate sponsorship totaling a few million dollars annually, with about a dozen paid contributors. That is a small team maintaining a systems language, and it explains the pace. Kelley has consistently refused venture funding on the grounds that it would create pressure toward decisions that serve investors rather than the language, a position that has cost the project speed and preserved its direction.
When to consider it
For a new production system, not yet. Pre-1.0 with breaking changes each release means an ongoing maintenance cost that most teams should not accept, and the ecosystem of libraries is thin compared to Rust or Go. The exception is a project where Zig's specific properties, no hidden control flow, no hidden allocation, and compile-time execution as a first-class feature, solve a problem the alternatives do not.
For cross-compilation tooling, immediately. Using zig cc to build C dependencies for multiple targets is a practical improvement available today with no commitment to the language, and the 0.16 size reduction removes the main objection. That is how most people will encounter Zig, and it is how a language builds a constituency before it is ready to ask for one.
The version number is the question everyone asks and Kelley has consistently declined to answer with a date. His stated criteria for 1.0 are a settled async design, a stable standard library, and a package manager the community trusts, and only the third is close. Reading the issue tracker, a 2028 release looks plausible and a 2027 one does not. That is a long time to ask people to wait, and the counterargument is that the languages which shipped 1.0 before their designs settled have been living with those decisions ever since.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
