# Returning to Zig

Anna Liberty's June 2026 post on gracefulliberty.com, tracing a path from Zig to Rust and back. The interesting part is that neither move was decided by the language: she left over release churn and came back over how the Rust project handled a policy argument.

## Why she left

She started with Zig in 2020, coming from C, after watching Andrew Kelley's *Software Should Be Perfect* talk. Fallible and explicit allocation, no hidden control flow, universal reusability — those became the properties she looked for everywhere. See [[zig]] for how those show up in the language and [[comptime]] for the mechanism underneath the abstractions she liked.

Then Zig kept breaking her code. As a student she often went months between touching a project, and each return meant refactors she didn't understand just to get back to a building state. This was before [anyzig](https://github.com/marler8997/anyzig) made multiple toolchain versions on one machine easy. The library situation compounded it: few packages, few examples to learn from, a standard library whose abstractions changed every time she thought she understood them, and documentation that was itself unstable.

Rust had been stable for years by then. Learning it hurt, but once learned it stayed learned, and it gave her a memory model that transfers to languages with fewer checks. She's explicit that she still likes the language.

## Why she came back

Her technical complaints about Rust are the familiar ones: difficult FFI, irritating cross-compilation, hidden and infallible allocations, and platform reach bounded by LLVM. A footnote added 2026-07-06 walks the last one back somewhat, after readers pointed out concrete work on alternative backends.

What actually moved her was governance. She notes the Rust Foundation's corporate members and the influence that money plausibly buys, but the trigger was the LLM-policy episode. Zig banned LLM-generated contributions outright — the reasoning behind that ban is [[contributor-poker]], and its visible cost is covered in [[simonw-zig-anti-ai]]. Rust polled, waited, and then published a proposal carrying a moderation rule that forbade PR comments touching four topics: long-term social or economic impact of LLMs, environmental impact, copyright status of LLM output, and moral judgments about people who use them. The rule was withdrawn after backlash. Her position is that the policy itself is fine and workable, and that the damage was the attempt to fence off the discussion. That episode is one data point in the pattern [[anti-llm-discourse]] catalogues, and it's the same class of problem as [[maintainer-governance-ambiguity]]: the code is not what people lost confidence in.

## Zig in 2026

Still unstable, and she says so plainly. Web examples for 0.16.0 were already outdated when she tried them; 0.17.0 is expected to break every project's build system. The counter-offer for tolerating that churn is [[zig-incremental-compilation]] — 50–70ms rebuilds, but only on `master` or 0.17, and only for `x86_64-linux`. Her working method is to keep a copy of the standard library source open, which she recommends as the fastest route to being productive.

Two things improved. The language proper changed little since 2020, so her instincts still held and unfamiliar library code was readable. And there's a package manager now, taking dependencies from git and tarballs with vendoring that works, replacing the git submodules she remembered. There's still no official registry, which she treats as deliberate rather than missing.

## The memory-safety section

She concedes Zig doesn't offer Rust's guarantees and frames the difference as safety per release mode rather than safety per block of code. ReleaseSafe crashes on failed asserts and initializes all memory; Kelley has floated pushing it further by shipping ReleaseSafe with something like [[fil-c]] underneath. The intended workflow is to test and fuzz in ReleaseSafe until illegal behavior has been shaken out, then ship a faster mode. In ReleaseFast the assertions stop being checks and become assumptions the optimizer is allowed to use, which only pays off if the testing really did prove those paths unreachable.

Her argument for it is not that this beats affine types, only that the complexity price of affine types isn't worth paying in every situation, and that when you'd be writing unsafe Rust anyway, Zig is the safer of the two. [[dayvster-manual-memory-management]] puts the same tradeoff side by side across C, Zig, Odin, C3 and Rust; [[zig-functional-programmers]] is the other direction, someone arriving at Zig from Haskell rather than from C.