Returning to Zig — Anna Liberty
Returning to Zig
From Zig to Rust to Zig again
2026-06-10 · 9 min · #computing
Zig is rising in popularity. It hasn't yet seized the space occupied by even Rust or Go, much less C, but it has been adopted by a few major projects and countless smaller ones. As such, it's becoming an important language for the future. having been interested in Zig for several years, I decided to check back in on the language and see how I feel about it today.
Why I Loved Zig
I was first introduced to Zig in 2020 by a programming mentor. They were passionate about this little new language with compile time code execution and beautiful yet simple forms of abstraction. I decided to check it out as well.
At the time, I was still deep in learning C. I enjoyed the power over my computer, but was frustrated by the dated abstractions and worse tooling. Zig, while new and unstable, was promised as a replacement for C. That hooked me. Why learn C when I could learn the next language?
I watched more of Andrew Kelley's talks. Software Should Be Perfect was formative. It shaped what I viewed what a programming language—and software in general—should look like. In that talk, Andrew emphasized the importance of fallible, explicit memory allocations, no hidden control flow, and universal reusability. Those were all values I began to look for in any programming language.
So I switched to Zig. I wrote toy programming languages, experimented with literate programming tooling, and played with Web servers. I enjoyed working with Zig. It felt nicer than C but without the footguns.
Leaving for Rust
Zig kept breaking my code. I grew tired of the churn. I was a student without much time to keep my code updated to work with the latest version of the language. This was before anyzig made it trivial to handle multiple versions of Zig on the same system. I often went months between working on particular projects. When I returned I would have to make major refactors I didn't understand to get them working again.
The Zig ecosystem was also immature. As a new programmer, I didn't have the skills to implement everything on my own. There were few libraries for anything and few examples to teach me. The standard library kept changing. Every time I thought I understood the way its abstractions worked, they would change. It didn't help that the default documentation was unstable.
So I left for Rust. At that point, Rust had been stable for years, with a strong ecosystem behind it. Learning it was a pain—I wanted to give up several times—but once I learned it, it worked. That was invaluable for me. A fast, lower-level programming language with the expressiveness I needed without the cost of instability. It also forced me to develop a mental memory model that served me well for languages with fewer built-in checks.
As a benefit, given the code didn't panic, I was able to write reusable code without hidden control flow or a garbage collector. While it did hide memory allocations and made working with C difficult, it brought me almost full circle to why Zig was appealing.
I love Rust. I enjoy working in it to this day. The abstractions bring me joy. Unfortunately, I'm concerned by some of the directions the project is going.
Why I'm Returning
Rust still isn't perfect. While it provides many of the things I was looking for in a programming language, it isn't the most ideal for making the reusable programs I want to make. FFI is difficult. Cross-compilation is irritating. Hidden, infallible memory allocations haunt me. Being shackled to LLVM it will be a long time, if ever, until it supports as many platforms as C.
Additionally, its governance still irks me. It has several giant corporate foundation members which almost certainly influence the way Rust is developed. When the biggest companies in the world are each giving you hundreds of thousands of dollars per year, you probably don't want to upset them.
Regardless of these, I was willing to accept these until the scourge of vibecoding hit the open source community. To my horror, many software projects were accepting LLM-generated code. I had thought LLMs were unpopular among developers. I figured the only people who used them were forced to by their employers.
When this happened, maintainers and users alike wrote or demanded LLM policies. Zig banned them from the project entirely. Meanwhile, Rust took its time. They did some polling and the general sentiment in the community was anti-LLM, but they weren't ready to make an official policy quite yet.
When they finally made a proposal, it included the notorious moderation policy:
No comment on this PR may mention the following topics:
Long-term social or economic impact of LLMs
The environmental impact of LLMs
Anything to do with the copyright status of LLM output
Moral judgements about people who use LLMs
It has since been removed after backlash, but the fact that this was the case at all caused me to lose...