Rust is so last year! Zig is the true replacement of C

I know, I know — the title is provocative. But hear me out. I've spent real time with Rust, I genuinely liked it for a while, and I've since changed my mind about where it belongs. Zig has quietly become my go-to for systems work, and I think it deserves a lot more attention than it gets outside of certain corners of the internet.

I was an early Rust adopter

I got into Rust early. Before the 1.0 release, back when the borrow checker would routinely make you feel like an idiot for writing a for loop. I stuck with it, learned the idioms, and came to appreciate what it was doing for me. The safety guarantees are real. The community is excellent. The tooling — cargo especially — set a high bar that most ecosystems still haven't matched.

So this isn't a hit piece. I respect what Rust is. It's just not the right tool for everything, and I think the community sometimes forgets that.

Rust struggles when requirements keep moving

Here's the thing: Rust's ownership model is brilliant precisely because it forces you to be explicit about who owns what and for how long. That rigour pays dividends when you have a stable, well-understood domain. But when requirements are shifting under your feet? It becomes a liability.

Refactoring a data model in Rust isn't just a matter of changing a struct. You're renegotiating lifetimes across the entire call graph. You fight the borrow checker not because your logic is wrong, but because the shape of your types no longer matches the assumptions baked in three layers down. In exploratory or rapidly-evolving projects, that friction compounds fast. What was a productive constraint becomes a wall.

I'm not saying Rust is bad at change — I'm saying the cost of change is higher than it looks on the tin, and that cost matters when the spec is still being written.

Enter Zig

Zig is a systems language that aims to be a better C rather than a safer Rust. It's explicit, low-level, and — crucially — simple. Not simplistic. Simple. There's a meaningful difference.

The language spec fits in your head. There's no hidden control flow, no operator overloading, no macros, no runtime. What you write is what runs. That predictability is enormously valuable when you're trying to move quickly and still understand what your code is doing.

The practical wins

A few things stood out immediately when I started building with Zig:

• Small, stable binaries. Zig produces lean executables with no surprises. Ship a single binary, done.

• Great developer experience. The build system is part of the language — written in Zig itself. No Makefiles, no CMake, no separate config DSL. Package management is sensible and improving quickly with the introduction of the package manager in 0.11.

• No libc dependency by default. This is a bigger deal than it sounds. On Linux especially, glibc version mismatches are a perennial source of pain when distributing binaries. Zig sidesteps the whole mess. Your binary runs on the target, full stop.

• No hidden semantics. Memory allocation is explicit — you pass an allocator, you know when memory is being allocated. There's no garbage collector silently kicking in, no implicit copies, no "magic" trait implementations rewriting the behaviour of your types. The code does what it looks like it does.

That last point deserves emphasis. One of my persistent frustrations with Rust is that the trait system — for all its power — can make it genuinely hard to trace what's actually happening at runtime. Zig has no such issue. Reading Zig code is like reading a slightly more ergonomic dialect of C. The semantics are right there on the surface.

Introducing Zooee

All of this is fairly abstract without a project to point at, so let me tell you about what I've been building. I've started a new UI library in Zig called Zooee.

It's early days, but it's already a more pleasant experience than I expected. Zig's comptime system is genuinely powerful for this kind of work — you can do a surprising amount of type-level computation without reaching for macros or code generation. The lack of hidden allocations keeps the library's behaviour predictable, which matters a lot for a UI layer where you want tight control over when things happen.

If you're curious, the code is up on GitHub:

https://github.com/daniel-samson/zooee

Contributions, issues, and opinions very welcome. I'm still finding the edges of what Zig makes easy versus what it makes awkward, and real-world feedback is the fastest way to learn that.

I'm not ready to say Rust is dead — it isn't. For a certain class of problem, particularly long-lived production infrastructure where the safety guarantees justify the upfront investment, it remains excellent. But for the kind of exploratory, fast-moving systems work I've been doing lately? Zig fits my brain better. It stays out of my way, does what I tell it, and doesn't pretend otherwise.

Sometimes that's exactly what you need.