A Rust developer with seven years of open-source experience decided to reimplement their JSONPath library — RFC 9535 compliant, production-used — in Zig. The goal was a fair fight: same spec, same author, same problem domain. What emerged wasn't a language war. It was a case study in what happens when you trade a borrow checker for manual allocator discipline across a real codebase.

The result: Zig is faster to compile, simpler to read, and genuinely refreshing for CLI tooling. It also surfaces four distinct memory-safety bug classes that Rust makes impossible by default. If your team is evaluating Zig for production systems, you need to know exactly where the manual work lives — and whether your on-call rotation can afford it.

The Reality: Allocators Are Everywhere, and You Own Every Byte

Zig's defining feature is explicit memory management. Every function that allocates takes an Allocator parameter. Every struct that owns heap data holds an Allocator field. The author calls this "relatively straightforward to follow" once you accept it as the cost of entry [1]. Then they spend the next several thousand words showing why that acceptance is exactly where production teams get burned.

The pattern is consistent: init allocates, deinit frees, and you must wire defer or errdefer at every call site. Miss one, and the TestAllocator catches it in CI — if your test exercises that path. Miss an error path, and you leak. Call deinit twice across ownership boundaries, and you corrupt the heap. Allocate an intermediate value, then fail to append it to a container, and you orphan the allocation.

Four bug categories, each with a minimal reproduction and a fix that requires human discipline every single time:

  1. Forgotten deinit — leaked cursor state. Rust: Drop runs at scope end, impossible to forget.
  2. deinit skipped on error path — early return leaks the iterator. Rust: Drop fires on any scope exit, including ? propagation.
  3. Double deinit across ownership transfer — cache holds shallow copy, caller frees, cache frees again. Rust: move semantics make the ownership transfer compile-time verified; the old binding ceases to exist.
  4. Orphaned allocation on partial append — dupe succeeds, append fails, string leaks. Rust: Vec::push moves the value in atomically; no fallible push returns an allocated-but-unlinked value.

Each fix is a one-liner: defer iter.deinit(), errdefer iter.deinit(), remove the defer after handoff, errdefer allocator.free(duped). Each fix relies on a human remembering to write it. In Rust, the compiler remembers for you.

The Pain Point: Your Team's Cognitive Budget

This isn't academic. The author's test suite catches these because they wrote tests that exercise failure paths using FailingAllocator with injected fault indices [1]. In production, your team must do the same for every allocation site, every error path, every ownership transfer. That's not a language feature — it's a process tax.

The author notes Zig's TestAllocator is "fairly reliable" once you write the cases [1]. That's the trap: reliability depends on test coverage of error paths, which is exactly what shrinks under deadline pressure. Rust's Drop gives you the guarantee without the test coverage. You still test logic, but you stop testing cleanup.

For a SaaS operator, this translates directly to on-call burden. Every manual deinit is a latent incident. Every ownership handoff across module boundaries is a design review. The author's double-free bug emerged from a three-layer call chain (processAll → cacheAndLog → runQuery) where ownership semantics were implicit in comments, not enforced by the type system [1]. In Rust, that code does not compile.

Failure Modes: Where Zig's Simplicity Becomes Liability

The author praises Zig's flat file structure — six files versus Rust's 20+ across nested modules [1]. That simplicity is real, and it scales further than expected. But it stops scaling exactly where memory ownership gets complex.

The functional paradigm mismatch compounds this. Rust's iterator combinators (map, filter, flat_map, reduce) express transformations as immutable pipelines. Zig forces mutation: in-place cursor overwrites, manual fork/deinit for branching, explicit while loops with index manipulation [1]. The author found the Zig result "less readable" subjectively, but the objective difference is that Zig's mutation requires more manual state management — more places to forget a deinit, more places to mishandle an error.

IDE support is nearly absent: syntax highlighting and basic autocomplete only [1]. The author ended up migrating to helix + alacritty + zellij — a viable personal choice, but a hiring and onboarding risk for teams. RustRover, VS Code + rust-analyzer, and CLion all provide refactoring, type-aware navigation, and inline error lens. Zig tooling isn't there yet.

The ecosystem gap is admitted: regex library mvzr lacks Unicode property escapes (\p{...}), blocking RFC 9535 filter functions [1]. The standard library API shifts between versions. These are growing pains, but they're real costs for teams betting on Zig today.

The Blueprint: How to Evaluate Zig Without Burning Sprint Capacity

If you're a systems architect or engineering lead considering Zig, run this evaluation checklist before greenlighting a pilot:

  1. Audit your error-path test coverage. Can your CI inject allocation failures at every append, dupe, init call? If not, Zig will leak in production. Rust leaks only if you explicitly Box::leak or create Rc cycles.
  2. Map ownership boundaries across modules. Draw the call graph where heap data crosses function boundaries. In Zig, every handoff needs a documented ownership protocol (errdefer on sender, no defer on receiver). In Rust, the compiler enforces it.
  3. Measure on-call maturity. Does your team have capacity to debug DoubleFree at 3 AM from a three-layer ownership chain? Rust moves those bugs to compile time.
  4. Prototype the hot path. Zig's compile times and binary size are genuinely impressive. Build your highest-throughput service in both.

Sources

  1. What Zig felt like, coming from Rust
  2. What Zig felt like, coming from Rust - Ziggit discussion