Zig is not yet at version 1.0, but it already powers a terminal emulator, a financial accounting database, and a critical piece of Uber’s infrastructure. The common thread across all three is that the teams adopted Zig for its compile-time control, C interoperability, and predictable performance — not for hype. With @bitCast semantics now finalized across all backends and the ELF linker reaching feature parity in master, Zig 0.17 is on track to be the most stable release yet for the production adopters interviewed here.
What Ghostty Built with Zig
Ghostty is a GPU-accelerated terminal emulator written entirely in Zig. The project is maintained by Mitchell Hashimoto and contributors, and it targets macOS, Linux, BSD, and Windows. Because Zig compiles to native machine code without a hidden runtime, Ghostty’s startup time and GPU compositing path stay inside a single binary with no managed runtime layer.
Two Zig features show up repeatedly in Ghostty’s architecture. The first is compile-time evaluation: Ghostty uses comptime to generate platform-specific rendering code at build time instead of runtime branching. The second is cross-compilation: the same codebase builds for Apple Silicon and x86_64 macOS from a Linux host without a separate sysroot. Those capabilities matter because a terminal emulator ships on every OS Ghostty supports, and maintaining four platform ports inside one language runtime would be a liability.
Ghostty also benefits from Zig’s memory model. By default, Zig does not have a garbage collector, and its allocator interface lets the terminal choose a region-based or pool allocator per surface. That design avoids the stop-the-world pauses that can make GPU-accelerated terminals stutter during rapid scroll or resize events.
What TigerBeetle Built with Zig
TigerBeetle is a distributed financial accounting database designed for correctness and low latency. Its ledger engine runs in-process on each node, and every entry is written to a replicated log with serializable isolation guarantees. The database is written in Zig, compiled to a static binary, and linked with a minimal allocator configuration.
TigerBeetle chose Zig because the language removes undefined behavior from the hot path. Financial accounting code is sensitive to integer overflow, uninitialized reads, and race conditions, and Zig’s strict overflow semantics and absence of data races in single-threaded comptime code make the correctness story auditable. The team also cites Zig’s lack of hidden control flow: there is no runtime type system, no JIT deoptimization, and no exception-based unwinding in the release build.
In October 2025, TigerBeetle and Synadia announced a combined $512,000 pledge to the Zig Software Foundation over two years (TigerBeetle). According to TigerBeetle’s public post, the commitment supports ongoing compiler development and ensures the project can rely on Zig as a long-term foundation rather than a short-term experiment.
What Uber Built with Zig
Uber has run binaries produced by Zig since April 2022 (Uber Engineering). The primary workload is cross-compilation for ARM64 infrastructure. In a public engineering post, Uber’s build team described how they replaced a fragile multi-toolchain setup with Zig’s zig cc frontend to produce hermetic C and C++ build graphs inside Bazel.
The motivation was operational. Uber’s previous ARM64 bootstrap required maintaining a separate toolchain, patching sysroots, and debugging link-time mismatches between Clang and GCC components. Zig’s zig cc exposes a single compiler driver that knows the ARM64 sysroot, the correct linker flags, and the standard library paths without manual configuration. The result is a build graph that is deterministic across developer laptops and CI workers.
Uber also signed a support agreement with the Zig Software Foundation to prioritize bug fixes. The contract value is disclosed in ZSF financial reports, and the arrangement gives Uber a direct escalation path on compiler issues that affect their ARM64 build farm.
What Is Changing in Zig 0.17
The development log for 2026 shows two concrete milestones that matter for production adopters. On May 30, the new ELF linker shipped support for incremental compilation on x86_64 Linux, cutting rebuild times for large Zig projects from minutes to roughly 200–300 milliseconds. On June 25, the compiler landed new @bitCast semantics that resolve miscompilations caused by LLVM’s untested bit-integer code paths.
Those changes land in master and are on track for the 0.17.0 tagged release (Zig Devlog). For Ghostty, TigerBeetle, and Uber, that means fewer linker crashes, faster edit-build-debug cycles, and a more predictable compiler backend. None of the teams treats 0.17 as a forced migration; they test against master continuously and freeze onto tagged releases only after validation.
Bottom Line
Zig’s lack of a 1.0 tag is not a blocker for the teams that have already embedded it in production. Ghostty ships a GPU-accelerated terminal to end users, TigerBeetle runs financial ledgers with static-linked Zig binaries, and Uber bootstraps ARM64 C++ builds at scale. The common thread is compile-time control, C interoperability, and a compiler backend that is finally maturing. When Zig 0.17 tags later this year, those teams will likely move to it faster than most language communities adopt stable releases.
Image: Ghostty (ghostty.org) — official social share card.
