Zig After Rust: A Four Months Delivery Review for ItInsightsWorld SoftwareDevelopment

This 2026-10-27 SoftwareDevelopment review expands a 15 min retrospective into an engineering checklist: after about four months of returning to Zig, the writer contrasts it with Rust, reports concrete project work, and extracts practical lessons for code review, tooling choices, and release planning.

Project Work: What Was Built Before the Verdict

The first deliverable was snurl, a library for the smallnet that covers Gemini, Finger, Gopher, Spartan, and similar protocols. The design target was a smaller-scale curl alternative with test and fuzz demands in mind, while following TigerStyle where practical.

A delivery lesson appeared early: the fuzzer was not truly working. An earlier expectation had treated the feature as usable, but it was incomplete. This was unsurprising for a pre-release toolchain, yet still sad because zig init places a demo in the generated main.zig file.

After snurl, the writer produced two programs that are not public yet: a small TUI typer racer whose minimal version was simpler than expected, and an n-body simulator with stellar evolution using raylib.

Zig Day Seattle: Community Signal for Local Development

The highlight was attending a nearby Zig Day. The event was discovered on Lobsters on August 20th, when the listing used the name Zig Day Seattle in Seattle. Knowing Andrew Kelley would attend made it better still.

Zig Days are local gatherings where people interested in Zig spend time together, hack on projects, and discuss Zig. For this session, the chosen work item was snurl, and Evin Yulo also came.

Registration pressure moved the venue from Bellevue library in Bellevue to Bothell library in Bothell; having the creator of Zig involved can do that.

The value was practical: the format linked local groups, produced face-to-face contact, and allowed project conversations with other programmers, including some ideological cross-pollination. In practice, snurl continued with evin, who began integrating Zig standard library TLS implementation as another backend. The writer also spoke briefly with Andrew Kelley and hopes Zig built-in fuzzing gets fixed soon. Ryan Hendrickson wrote an excellent same-day piece from his perspective. The writer plans to attend Zig Day Seattle again and might go to Portland before the next nearby Zig Day, because meeting people interested in Zig and its values matters.

Engineering Features That Improved the Workflow

Version Switching With anyzig

anyzig made zig master and 0.16.0 manageable across projects. The limitation is that it cannot act outside a directory that contains build.zig.zon. If a tool requires zig, it must run inside a project directory, which breaks autoformatting for quick one-off Zig scripts. A default zig version might help.

Explicit IO and Allocators

Although some people dislike it, the writer likes that functions receive explicit IO and allocator parameters. For allocators, each function that allocates must take an explicit allocator. Compared with a default global allocator or implicit context system, as in Odin, this style makes clear whether a function allocates and makes accidental allocator passing hard. It also supports different code areas: arena allocator, general-purpose allocator, or FixedBufferAllocator, helping memory-heavy programs be reasoned about.

Compared with Rust, Zig avoids hidden allocations. Rust tends to hide allocations, and exhaustion can panic. Rust is moving toward explicit allocation, but that can feel bolted on rather than designed from the beginning.

IO as Portability and Test Seam

The IO parameter was worth breaking changes, even though the 0.15.0 to 0.16.0 transition was skipped. Functions that touch the operating system, with caveats, require IO supplying input, output, and context. Porting Zig to another OS is mainly porting IO. Tests can use a crafted IO instance, alter input streams, force writes to fail, or otherwise shape behavior. Passing IO reveals whether a function is pure or may affect the outside world, consistent with avoiding 100 little near-duplicate features and providing one broad capability with a low floor and high ceiling.

Comptime and Build System

Comptime combines metaprogramming and precomputation smoothly; others have explained it more deeply, so this note stays short. The build system is excellent; its quality attracted companies such as Uber, which uses it for software written in other languages. Other tools can be integrated seamlessly, especially for code generation, where Cargo becomes annoying.

Dependency Culture and Error Handling

Zig dependency culture avoids dependencies unless needed. When needed, libraries are often battle-tested and can be brought in with translate-c. Vendoring and auditing external code is easy. Most Zig programs have about one or two direct Zig dependencies and zero indirect dependencies, making auditing simpler. In Rust, even small projects often carry a few direct dependencies and dozens indirect ones. Some of this is culture; some is that Zig places reflection, random number generation, clean error handling, and JSON parsing in the language or standard library, reducing the need for serde or syn in every codebase.

Zig nudges programmers toward error handling by default. The laziest approach is try plus ! in a return type. Rust more easily encourages inserting panics while prototyping and leaving them in production; some Rust production code panics instead of returning proper errors. Rust can use ?, shorter than unwrap, but may force verbose Result types. anyhow and anyhow::Result provide helper methods, but require a dependency for convenient errors; another library can offer composable errors in Zig style.

Incremental Compilation Feedback Loop

The core Zig team incremental compilation work is impressive. zig build --watch -fincremental makes the compiler monitor changes, inspect what changed, and only recompile and relink delta. It can operate faster than human perception even on large codebases, because Zig was designed for this behavior. The workflow keeps the compiler beside editor and gives feedback on save, without distraction gaps. In Rust projects, even small ones, 10+ seconds incremental compilation loops are common. Rust stability and backwards-compatibility constraints make compilation speed changes harder, while Zig maintainers will break almost anything if it leads to a better final language. Currently Zig supports incremental compilation on x86_64 on Linux and macOS; other platforms lack it for now.

Engineering Gaps to Watch Before Standardizing

Stability Around 1.0

Standard library stability remains a user priority. The writer knows that is one of the last jobs before 1.0, and many others remain. The delay of 0.17.0 was partly caused by constant ecosystem breakage. Andrew Kelley told participants at Zig Day that he wants 1.0 more than anyone. The result is patience, plus use of Rust when certain work needs a stable language and ecosystem. Still, impressive software is being built in Zig now, stability is not everything, and for some projects Zig advantages outweigh instability.

Lifetime Support

More compiler help with lifetimes is desired. Returning local variables should fail in debug mode, either as a built-in lint discussed by Andrew Kelley, or by invalidating memory after the function returns. That would teach newcomers quickly, because it is easy to accidentally break code even when one thinks they understand lifetimes. The compiler also accepts code that could become invalid later, because variables can live through an entire scope rather than just a block. A stack buffer returned from a block should be invalidated but may not be. The example warns This works but will be invalid. A pattern using buf : [1024]u8 can look fine yet become invalid in a future Zig version.

Documentation Depth

Documentation is a weak spot. There is enough to start, but deeper understanding often must be inferred from sparse doc comments attached to functions, and examples are scarce. The writer still cannot make Zig standard library TLS work in snurl because correct buffer setup is unclear to the writer and a friend. Much practical Zig knowledge is spread across the Web. People deeply integrated in communities can succeed; others may struggle. On the plus side, this pushes people toward communities, such as the Matrix room where the writer is admin. While LLMs can undermine human collaboration, human-to-human help still matters; good docs can coexist with strong community support, and good communities can point to resources instead of merely repeating RTFM.

Comptime Allocators

Compile-time JSON parsing would help one project where a static JSON file is stored inside the binary and could be converted at compile time into structs. The standard library JSON parser requires an allocator, and because no allocator works at compile time, parsing happens at runtime. There may be intent to add an allocator-free JSON parser, since the data already lives in the JSON string. That would address this case, but broader cases may still need an allocator. FixedBufferAllocator once worked at compile time for this, and it could again.

Bootstrap Path and Packaging

Zig bootstrapping story is remarkable. The C++ compiler was removed and replaced with a small WASM blob and WASM interpreter. The WASM blob contains a stripped-down compiler that builds the full Zig compiler into C, which the system C compiler then builds. The approach is interesting, though it requires a checked-in binary blob. That is better than needing the previous full compiler, as Rust does, but worse than having source for every step. A malicious actor could still sneak something inside the blob. More practically, distributions such as Debian cannot properly package Zig right now because their guidelines cannot be met. The original plan to use the C backend to generate a separately maintained C version, producing two different source versions, was judged too difficult. Therefore, someone will probably need to write another Zig compiler in another language, likely C, to improve bootstrapping, which the Zig Software Foundation does not want to develop now. There is no fully source-only bootstrap today. Because Zig cannot be packaged on Debian, the writer had to pick another language for one project to reach wider use. The issue should be temporary: once Zig is stable, an alternative compiler may be straightforward, because Zig is designed to be simple and feasible to reimplement, unlike some languages. For now, instability would make any alternative compiler constantly chase the main one, likely why the core team avoids managing it during rapid iteration. This may need to wait for 1.0.

Tooling Comparison: Zig Versus Rust in Delivery Context

Delivery concern	Zig	Rust
Allocation visibility	Explicit allocator parameter reveals allocation	Often hidden; exhaustion can panic; moving toward explicit
Dependency tree	Usually about one or two direct and zero indirect	Small projects can have a few direct and dozens indirect
Error habits	try and ! nudge error return	Prototyping may leave panics; ? may require verbose Result; anyhow needs dependency
Build workflow	Build system integrates code generation; attracted Uber	Cargo can become annoying with extra tool integration
Compilation loop	watch incremental can feel immediate; x86_64 on Linux and macOS	10+ seconds loops common even in small projects
Stability posture	pre-1.0, 0.17.0 delayed by breakage	Stability and backward compatibility can slow compilation optimization

Actionable Steps for a Zig Pilot

1. Start a bounded project such as snurl for smallnet, with explicit test and fuzz demands and TigerStyle checks.
2. Verify zig init expectations before trusting a generated main.zig demo.
3. Use anyzig inside a build.zig.zon project directory, not outside it.
4. Make allocator and IO parameters part of design review.
5. Keep dependencies small, audit vendored code, and use translate-c for battle-tested libraries only when needed.
6. Track Zig Day Seattle and Zig Days to convert online notes into local project feedback.
7. Use Rust for deliverables needing a stable ecosystem while monitoring 1.0, documentation, lifetime support, comptime allocators, and Debian packaging.

Common Mistakes From This Four Months of Work

• Assuming the fuzzer works just because a starter test exists.
• Trying anyzig without build.zig.zon.
• Ignoring explicit IO and allocator consequences, making tests and porting harder.
• Returning local buffers and thinking lifetimes are understood; invalid examples can compile.
• Relying on sparse docs instead of community review for TLS and buffer setup.
• Expecting compile-time JSON parsing without allocator support.
• Planning distribution packaging without checking Debian and bootstrap constraints.

FAQ: Practical Questions Raised by the Zig and Rust Comparison

Why does explicit allocator and IO matter?

It reveals allocation and system effects, simplifies testing with crafted IO, supports different allocator strategies, and clarifies OS porting.

Why still use Rust after adopting Zig?

Some work needs a stable language and ecosystem; Zig pre-1.0 churn, 0.17.0 delay, and packaging issues can make Rust safer for that scope.

What would make Zig easier for teams?

Stronger stability around 1.0, clearer lifetime support, deeper documentation, compile-time allocator options, and a source-only bootstrap path.

What was the community signal?

Local Zig Days created linked groups and direct work on snurl, TLS backend integration, and conversations with Andrew Kelley, Evin Yulo, evin, Ryan Hendrickson, and others.

Final Decision: Continue With Zig, Keep Rust for Risky Delivery

The plan is to keep using Zig. Even with flaws, the writer found no programming language preferred over Zig. It is stable enough to avoid enormous changes between releases, so it remains the default for most projects. ReTangled moves away from Rust after fatigue with huge dependency trees and reliance on the Zig build system. The writer wants to contribute more directly to Zig, but student time is limited, there is an overflow of contributors, and poor documentation makes onboarding difficult. Improving contributor onboarding seems a priority for Andrew Kelley. The expectation is future Zig Day Seattle events and continued project work, with 1.0, documentation, lifetimes, comptime allocators, and bootstrap as watch items.