P99 CONF - Zig vs Rust

The central takeaway from this P99 CONF panel is a practical split between Rust and Zig for systems and high-performance work: Rust is framed as the “safe and boring” default for infrastructure thanks to memory safety and broad ecosystem momentum, while Zig is pitched as the language of choice when developers want maximum control with fewer hidden behaviors—even if that means leaning harder on compile-time code generation.

Pekka (Turo) makes the Rust case around memory safety and infrastructure readiness. He argues that systems programming leaves few viable options, and that Rust’s approach has helped it move from niche to mainstream enough to be used in major environments, including Linux kernel work and Microsoft efforts. He also cites adoption stats—roughly 7 million C++ developers versus 1–2 million Rust developers—to support the claim that Rust is already “accepted” for building critical software. In his framing, Rust’s value is less about novelty and more about reducing catastrophic failure modes while still fitting the needs of performance-focused infrastructure.

Jared (Bun) counters with Zig, emphasizing predictability: no hidden behavior, no operator overloading, and no constructors/destructors that can obscure what runs when. Zig’s appeal, he says, is control “down to the details,” paired with safety features available out of the box. The panel then drills into Zig’s compile-time (comptime) as the flashpoint. Pekka describes comptime as something he struggled to understand and ended up using “everywhere” during a months-long Zig project, calling it a rabbit hole of magic. He contrasts that with the idea that macros in other languages are usually constrained, whereas comptime can propagate widely.

Jared pushes back: comptime is not just for types—it also replaces parts of the build system and enables maintainable code generation. He gives a concrete Bun example: generating a lookup table at compile time for decoding variable-length integers used in source maps (base64-related line/column mapping). He also argues that comptime is idiomatic for Zig’s strengths, while acknowledging that overuse can create problems—just like overusing allocations can.

The discussion shifts to learning and tooling. Zig’s resources are described as sparse, and early experience can feel like “fighting the compiler,” though that pain fades as developers learn the language’s limited error patterns. Jared says he learned largely by reading Zig’s standard library and system-call documentation, plus leaning on Zig Discord for fast answers. On developer experience, the panelists compare Rust’s borrow-checker learning curve and compile-time costs to Zig’s faster compilation, while noting that modern Rust tooling (e.g., editor diagnostics) can reduce day-to-day friction.

Finally, the panel addresses distribution and portability. Globber (Turo) argues Zig’s ability to generate self-contained binaries simplifies shipping across platforms, while Rust distribution can become complicated when dependencies pull in shared libraries (e.g., SSL). Jared responds that Rust isn’t “impossible,” but portability tradeoffs show up early and repeatedly—especially when performance work forces platform-specific implementations. The panel closes by debating interfaces/traits in Zig (hand-rolled vtables and comptime-based patterns) and by looking forward to systems-language trends, including Mojo’s Python-like syntax aimed at performance, with skepticism about replacing Python beyond machine learning.

Overall, the conversation lands on a clear decision framework: choose Rust when you want a mature, safety-first ecosystem for infrastructure; choose Zig when you want explicit control and are willing to embrace comptime and lower-level patterns to get predictable performance and simpler distribution artifacts.