Why I Returned to Zig After a Stint with Rust

Why I Like Zig

Zig’s popularity is rising, though it has not yet captured a market share comparable to Rust, Go, or C. The author, interested in Zig for several years, revisits the language to reassess his current view.

His first exposure to Zig was in 2020 via a mentor who praised its compile‑time code execution and clean abstractions. At the time he was learning C and found its outdated abstractions and poor tooling frustrating, making Zig’s promise to replace C appealing.

Inspired by Andrew Kelley’s talk “Software Should Be Perfect,” which emphasized explicit memory allocation, no hidden control flow, and reusable abstractions, the author began experimenting with Zig, building toy languages, literary programming tools, and a web server, finding Zig friendlier than C and free of C’s fatal flaws.

Switch to Rust

Zig’s frequent breaking changes and immature ecosystem (few libraries, unstable standard library, changing documentation) forced the author to switch to Rust, which had a stable runtime and a strong ecosystem. Learning Rust was painful but ultimately rewarding; its speed, low‑level expressiveness, and lack of instability matched the author’s needs, and it forced him to develop a mental model useful even for less‑checked languages.

However, Rust’s FFI difficulties, cross‑compilation hassles, hidden memory allocations, and reliance on LLVM raised concerns. The author also grew uneasy with Rust’s governance, noting large corporate foundation members and a controversial “vibecoding” episode where open‑source projects adopted LLM‑generated code, leading to a strict LLM ban in Zig and a more cautious, poll‑driven response in Rust.

Why I Returned

Disappointed by Rust’s management and LLM policy, the author re‑examined Zig. He observed that Zig 0.16.0 examples were outdated, but keeping a copy of the standard library source helped navigate changes. Anticipating Zig 0.17.0, he expects further breaking changes as part of stability improvements.

Since 2020, Zig’s core language has changed little, allowing most of his code to remain usable. New features like a built‑in package manager simplify dependency handling compared to earlier Git submodule approaches, and overall workflow runs smoothly.

Although Zig’s ecosystem is still limited and intentionally avoids a central package repository, the author feels this aligns with Zig’s design philosophy and provides a balanced toolset.

Memory Unsafety

Zig does not offer the comprehensive compile‑time memory safety guarantees of Rust, a trade‑off made for simplicity. The author argues that Zig code can still be safer than unsafe Rust code, especially when using the ReleaseSafe mode, which crashes on assertion failures and initializes all memory.

Future improvements like integrating tools such as Fil‑C aim to enhance safety, though they won’t match Rust’s compile‑time guarantees unless the unsafe keyword is avoided.

Memory safety is viewed as a spectrum; Zig’s approach focuses on runtime safety in ReleaseSafe mode, supplemented by testing and fuzzing, whereas Rust relies on a strict type system. The author suggests choosing the language that fits the specific use case and tolerance for complexity.

Conclusion

Zig now has a stable standard library and versioning, and the author is prepared to use it for future software challenges. While he may still opt for Rust when its stability or type system is essential, Zig’s user‑centric philosophy and commitment to software quality resonate with him, reinforcing the belief that multiple languages should coexist.