And why are people using it without writing a line of it?
Most programming languages spread because developers write code in them. A developer tries the syntax, likes the ergonomics, builds something, and tells a colleague. Some languages gain traction through adjacent tooling or frameworks – TypeScript through Angular, Kotlin through Android – but the language itself is still the point. The tooling serves the code.
Zig has followed a different path. One of its most widely discussed real-world uses is zig cc – a drop-in C and C++ cross-compilation toolchain that teams adopt to compile code written in other languages, without writing or intending to write a single line of Zig. Uber engineers have adopted it for C++ cross-compilation. The Bun JavaScript runtime chose Zig partly for the language but substantially because the toolchain solved cross-compilation problems that were otherwise intractable. These are prominent examples rather than proof of universal adoption – the evidence base is still developing – but the pattern is consistent enough to demand explanation, particularly for a project that has not yet reached version 1.0. The language enters organisations through the compiler, not through the syntax.
The standard description of Zig – "a better C" – is accurate in the narrow sense that Zig occupies the same layer of the software stack and shares C's execution model.
But it obscures the more interesting truth: where Rust fixes C by replacing the language with a fundamentally different memory model, Zig fixes C by rebuilding its infrastructure – the compiler, the build system, the cross-compilation machinery – into a hermetic, portable package, while leaving C's raw execution model and ABI intact.
Rust replaces C's code but keeps C's interfaces; Zig rebuilds C's tools but keeps C's physics.
The toolchain
The first article in this series argued that C's importance derives from the ABI – the universal binary interface that every other language targets at its boundaries. If that is true, then the tool that manages that ABI most competently acquires strategic importance. Zig understood this before most of its competitors did.
zig cc bundles a patched Clang/LLVM frontend with platform headers into a single, portable binary. A developer can cross-compile C or C++ to any supported target from any host machine without installing platform-specific toolchains, sysroots, or header packages. The crucial detail is that Zig ships what it calls bundled libc targets – musl and glibc headers for many architectures – inside its own distribution. That is what makes the cross-compilation hermetic rather than merely convenient.
Without Zig, building a C program for Linux ARM64 from a macOS x86 host typically requires installing a cross-compiler, obtaining the correct sysroot, configuring include and library paths, and debugging linker errors. The process is fragile, poorly documented, and different for every target triple.
Traditional cross-compilation for Linux ARM64 from macOS:
# Install a cross-compiler, obtain a sysroot, configure paths...
brew install aarch64-linux-gnu-gcc
export SYSROOT=/path/to/aarch64-linux-gnu/sysroot
aarch64-linux-gnu-gcc -o myapp main.c \
--sysroot=$SYSROOT \
-I$SYSROOT/usr/include \
-L$SYSROOT/usr/lib
The same operation with Zig:
zig cc -target aarch64-linux-gnu -o myapp main.c
zig cc reduces this to a single command with the target specified as a flag.
The strategic consequence is unusual. Every other "better C" language asks developers to leave the C ecosystem. Zig absorbs it. A team can adopt zig cc without writing a single line of Zig, without changing any source code, and without altering any interfaces. The cost of adoption is close to zero. The language becomes available as an option once the toolchain is already in use. The toolchain opens the door; the language follows.
The contrast with Rust is instructive. Both languages interoperate with the C ABI, and both use LLVM as a backend. The real difference is the memory model: Rust replaces it; Zig retains it. Rust's FFI requires extern "C" blocks, unsafe wrappers, and often a binding generator such as bindgen:
// Rust: calling C's strlen requires an unsafe block and a manual declaration
extern "C" {
fn strlen(s: *const c_char) -> usize;
}
fn length(s: &CStr) -> usize {
unsafe { strlen(s.as_ptr()) } // every call crosses an unsafe boundary
}
Zig can @cImport a C header directly, which works by invoking zig translate-c under the hood – a mechanical translation step that parses C declarations into Zig types:
// Zig: import the C header; call the function as though it were Zig
const c = @cImport(@cInclude("string.h"));
fn length(s: [*:0]const u8) usize {
return c.strlen(s); // no wrapper, no unsafe block, no binding generator
}
The interop cost is structurally lower because Zig kept C's memory model and calling conventions.
Transparency
If the toolchain is Zig's adoption strategy, transparency is its design philosophy. Zig's stated principle is: no hidden control flow, no hidden allocations. If you do not see a function call in the code, no function call occurs. If you do not see a memory allocation, no memory is allocated. Every operation is visible at the call site.
This is easier to understand through a concrete comparison. Consider a routine operation: appending an element to a dynamic array.
In C, realloc may be called inside a library function. The caller cannot tell from the call site whether memory will be allocated, how much, or what happens on failure. The convention is to check a return value, but nothing in the language enforces this.
In C++, std::vector::push_back may reallocate the backing buffer, invoke copy or move constructors, and – if an exception is thrown – unwind the stack through destructors. None of this is visible at the call site. The programmer must know the type's implementation to reason about what happens.
// C++: what happens behind this line?
items.push_back(value);
// Answer: possibly realloc, possibly copy/move constructors on every element,
// possibly an exception, possibly stack unwinding through destructors.
// The call site tells you none of this.
In Rust, Vec::push may reallocate. When the old buffer is dropped, Drop runs automatically. The borrow checker prevents dangling references, but the programmer cannot see from the call site alone what cleanup will occur or when.
In Zig, the function takes an Allocator parameter explicitly. The append call returns an error union. If allocation fails, the error is a normal return value in the caller's control flow. No destructors run. No exceptions are thrown. No implicit function calls occur. The call site is a complete description of what the machine will do.
fn appendItem(list: *std.ArrayList(u32), allocator: std.mem.Allocator, value: u32) !void {
try list.append(allocator, value);
}
The point is not that the other languages are wrong. Each hides a different amount of machinery behind the call site, and each has reasons for doing so. Zig hides the least. The cognitive load of reasoning about what a line of Zig does is lower than the equivalent line in C++, because there is less invisible behaviour to account for.
The allocator pattern
The explicit allocator is central to how this works in practice. Zig's standard library functions that allocate memory require an Allocator to be passed as a parameter. This single design decision has several consequences.
Any function signature that includes an Allocator parameter declares, at the type level, that it may allocate memory. Any function signature that does not include one is guaranteed not to allocate. Tests can substitute a different allocator – a failing allocator, a tracking allocator, a fixed-buffer allocator – without changing the code under test. In systems with strict memory budgets – embedded devices, databases, game engines – the allocator pattern makes resource consumption auditable at the API boundary. And out-of-memory is a normal error return, not an abort or an exception. The caller decides what to do.
In C, allocation failure is easy to ignore:
// C: nothing forces the programmer to check this
char *buf = malloc(4096);
memcpy(buf, src, len); // if malloc returned NULL, this is undefined behaviour
In Zig, the error is part of the return type and the compiler will not let the caller ignore it:
// Zig: the caller must handle the error or explicitly propagate it
const buf = allocator.alloc(u8, 4096) catch |err| {
// OOM is a normal control flow path, not an abort
return err;
};
Resource exhaustion becomes a first-class engineering concern rather than a runtime surprise.
The trade-off must be stated honestly. Zig does not prevent use-after-free, dangling pointers, or data races at compile time. It keeps C's physics – including the dangers that come with them – and the programmer remains responsible for memory correctness. Zig's position is that if every operation is visible and every allocation is explicit, the programmer can reason about correctness directly – and that this is preferable, for certain classes of work, to the indirection and constraint of a borrow checker. Whether that bet pays off at scale is an open question. Zig's largest production users suggest it can, but the evidence base is still narrow compared to Rust's.
Comptime
Comptime is the mechanism that keeps the language small despite its toolchain ambitions. Zig's toolchain does a great deal; the language itself does remarkably little, because comptime collapses several distinct features into one.
Any expression or block in Zig can be marked comptime, which instructs the compiler to evaluate it during compilation rather than at runtime. The code that runs at compile time is ordinary Zig – the same syntax, the same semantics, the same standard library. There is no separate macro language, no template metalanguage, no preprocessor.
| Language | Compile-time mechanisms |
|---|---|
| C | Preprocessor (#define, #ifdef) |
| C++ | Templates, constexpr, macros |
| Rust | Generics, proc macros, const fn, build.rs |
| Zig | comptime (one mechanism) |
The structural consequence is most visible in how generics work. Zig does not have a generics subsystem. In Rust, generics are a distinct wing of the compiler architecture with their own syntax, trait bounds, and monomorphisation rules. In C++, templates are an entire sub-language with its own error messages, its own instantiation model, and its own debugging challenges:
// C++: a generic linked list requires the template sub-language
template <typename T>
struct LinkedList {
struct Node {
T data;
Node* next = nullptr;
};
Node* head = nullptr;
};
// Errors in templates produce notoriously unreadable diagnostics.
// The template system is a distinct language-within-a-language.
In Zig, a generic data structure is a function that takes a type parameter at comptime and returns a struct:
fn LinkedList(comptime T: type) type {
return struct {
const Node = struct {
data: T,
next: ?*Node = null,
};
head: ?*Node = null,
};
}
That entire architectural wing – generics, template specialisation, trait resolution – is deleted and replaced by a function call that happens to run at compile time. One mechanism does the work of four. This is simplicity in the sense the Clojure article in this series discussed – fewer entangled concepts, fewer distinct syntactic forms – rather than mere ease of use.
The build system is where comptime meets the toolchain. Zig's build system is a Zig program – not a separate tool like Make, not a separate language like CMake, not a domain-specific configuration format like Cargo.toml. Because the build system is Zig, it has full access to comptime, to the standard library, and to the same cross-compilation targets as the compiler. It can orchestrate mixed C/C++/Zig builds, conditional compilation, dependency fetching, and platform-specific logic – all in one language, in one file. This is the structural link between the toolchain story and the language design: the build system is where they meet.
Where Zig's design assumptions match reality
Three conditions align with Zig's architecture.
The first is an existing C or C++ codebase that must be maintained, not rewritten. The codebase is too large to port to Rust. The build system is fragile. Cross-compilation is manual and error-prone. Zig enters as the toolchain first – zig cc replaces the existing compiler without changing any source code. New modules can then be written in Zig and linked against the existing C code with no FFI layer, because Zig can @cImport C headers directly. This is a gradual adoption path with near-zero switching cost, and of the three conditions, it is the strongest match for Zig's design.
The second is deterministic, resource-constrained systems: databases, game engines, embedded firmware, custom allocators – systems where garbage collection pauses are unacceptable and where the borrow checker's constraints impose friction on the data structures the problem requires. Intrusive linked lists, arena allocators, and memory-mapped I/O are all straightforward in Zig and often require unsafe abstractions in Rust. The explicit allocator pattern makes resource budgets visible and OOM handling a normal code path.
The third is cross-platform binary distribution from a single build environment. A CLI tool, a library, or a runtime that must ship to multiple OS/architecture combinations from a single CI pipeline. Zig's hermetic cross-compilation produces static binaries for each target without requiring platform-specific toolchains on the build machine – and notably, it makes static linking against glibc significantly easier than standard toolchains do, which has historically been a major pain point for C developers targeting Linux. What would otherwise be a multi-day infrastructure project becomes a build flag.
Where Zig's assumptions do not match: if compile-time memory safety guarantees are required, Rust provides them and Zig does not. If a mature ecosystem with extensive library coverage is needed, Rust and Go are years ahead. If API stability between releases is essential, Zig is not there yet. These are not minor caveats.
Limitations
Zig's limitations are significant and should be weighed honestly.
The language is pre-1.0. The standard library APIs have broken between releases and will continue to do so until the specification stabilises. Code written against Zig 0.11 may not compile on 0.13. For production systems, this imposes a maintenance cost that must be weighed against the language's benefits.
Documentation is incomplete. The standard library documentation is auto-generated and sparse. The language reference is thorough but dense. There is no equivalent of the Rust Book or Go Tour – no structured onboarding path for new developers. The primary learning resource remains reading the standard library source code, which is a high barrier to entry.
The package ecosystem is young. Many common libraries – HTTP, JSON, database drivers – exist but are maintained by small teams or individuals. The depth and breadth of crates.io or PyPI is years away. IDE support via ZLS (the Zig Language Server) is functional but less complete than rust-analyzer or gopls. Debugging and profiling support exists through LLVM but is not as well documented as for C or Rust.
There is also the question of AI-assisted development. LLM coding tools are trained predominantly on C, Python, JavaScript, Java, and Rust. Zig's representation in training data is thin. AI-assisted development – an increasingly material factor in language productivity – is less reliable for Zig than for mainstream languages. This gap is likely to narrow, but it has not done so yet, and for teams that rely heavily on agentic coding workflows the practical impact is real.
Competitors
Zig is not the only language attempting to improve on C. Odin prioritises data-oriented design and developer ergonomics – while Zig rebuilds the toolchain for the programmer's environment, Odin builds a better language for the programmer's data. Hare prioritises minimalism and stability, with its own compiler backend (QBE) and a stated intention to freeze the language specification at 1.0. Nim transpiles to C and therefore operates as part of the C infrastructure by definition, though it relies on the host's C compiler rather than shipping its own. C3 stays closest to C's syntax while fixing the preprocessor and adding contracts.
Each made different strategic choices about the toolchain question. Zig is the most prominent language to ship a drop-in C/C++ compiler as a first-class, maintained component of its distribution.
Conclusion
Zig's strategy for entering the systems programming landscape was to recognise that C's dominance rests on infrastructure – the ABI, the toolchain, the build process – not on the quality of the language. Rather than building a better language and hoping the infrastructure would follow, Zig rebuilt the infrastructure and let the language follow.
Whether that strategy succeeds long-term depends on reaching 1.0, stabilising the API, and building an ecosystem deep enough to sustain production use at scale. Those are open questions. But the approach itself – rebuilding the toolchain while keeping the physics – is the most original strategic move in systems language design since Rust replaced the memory model while keeping the ABI.
In systems programming, the compiler has always mattered more than the language. Zig is built on that conviction.
This article is part of an ongoing series examining what programming languages actually are and why they matter.
| Language | Argument |
|---|---|
| C | The irreplaceable foundation |
| Python | The approachable ecosystem |
| Rust | Safe systems programming |
| Clojure | Powerful ideas, niche language |
| Zig | Rebuild the toolchain, keep the physics |
Coming next: Odin – a language for developers who ship software, not papers about shipping software.
Top comments (0)