Why Zig over C for Systems Programming

Zig is a nice language, but those articles always compare new languages against old-style C without use of modern tools. Most of the listed advantages you can have in C as well if you are willing to adopt modern tooling and style: signed overflow checking: sanitizers, errors you can not ignore: [[nodiscard]], slice type which know their size: variably-modified types or span types.

Defer will also appear in C compilers soon, but personally I still think goto-error handling is clearer.

(Rust has an advantage for temporal memory safety, but this does apply to Zig.)

I've been toying with the idea of learning zig and weirdly enough I was looking at this guys book. I don't have any experience with low level languages. The closest I've gotten is Go.

I was debating between C and Zig, but I still don't really know what I want to choose. Feels like C is probably the right choice given the languages age and it could technically be more useful (not that I'd be looking for a job doing C work).

For those that know both, what would you pick?

I’ve settled on a dialect of C++ for systems programming after using C for a long time. It’s mostly C-like and I disable exceptions, RTTI, etc. but I do use templates, overloads, methods, lambdas, etc.

I have my own object system with constructor methods that all return a status code so you don’t need exceptions, my own stdlib for containers, buffered I/O, networking, hashing, math, threading, async, etc.

C++ gives you all the features to effectively build your own language, and you can use first class tooling since C++ is widely supported. LLMs also make it much easier to build out and test an entire stdlib on your own.

Also, Zig is as at least as expressive as C++ (but without the implicitness and general language complexity that makes reviewing some sensitive code, where you need to see exactly what operations are performed, hard), and it supports arenas better than C/C++/Rust.

All these new languages are unreadable relative to C. If, like me, you like explicit stuff like for (size_t i = 0; i <= n; i++) total += a[i]; all these new languages won't do it.

D and Nim have had the same features for years btw.

Rust will take over all these niche languages anyway. Yes, Rust is a viable replacement for C and C++ in the long term. Zig is just trying to be a middle ground, which we've established doesn't work. Zig is particularly irrelevant compared to Rust in the LLM era.

> Errors you cannot ignore

It's okay for me to declare a macro with `__attribute__((warn_unused_result))` for GCC and Clang, and `[[nodiscard]]` when the C code is later compiled with C++ (or nothing).

Is Zig stable yet? No.

AI slop. Every article on this site has "The honest tradeoff" as a header. Looks like it was generated to promote a book which is no doubt also just slop.

I wrote recently about a weird issue I encountered with Zig, though to be fair it was related to using Zig to compile C code, humorously in a Rust project (which touches on all of the languages mentioned in this post).

https://dennisforbes.ca/blog/microblog/2026/10/the_accidenta...

While I did just dismiss it as an edge issue, it turns out that this same rather clumsy sort of mistake has happened repeatedly in Zig's pure rewrite of MUSL. And despite being an absolutely catastrophically bad problem, by my judgment, the problem is still in main at this moment, across a wide number of musl function rewrites.

Which gives me pause about the whole zig project. If you're rewriting a critical library, making such simple but consequential mistakes shouldn't happen, and if they do happen it should be a red alert type situation.

C is far behind the sate-of-art in C and Go families. True, but not bad.

It is what it is, but can work on what it already has, while keeping its tradition. Small changes, add common extensions, conservative additions, improve coherence and correctness of the standard while keeping easy to implement and small.

No crazy things.

Keep in mind that it is standardized and targets things others do not target.

Yeah

The lack of a native slice is the most glaring C fault I think exists

(And of course the committees won't implement it, and of course C is going to remain broken)

"C is not going away and I still read a lot of it, because the UNIX source code and most system libraries are written in C and their man pages document them with C prototypes. But for new code I choose Zig."

Has this aged well though?

The TechBros pour in tons of money into "agentic programming" or "agentic workflows" right now. You can see that all over the place; OmarchySlop and other AI-controlled projects, where Claude is now the main designer. So in such a scenario, where does Zig really fit in? The "but for new code I choose Zig" is not a really compelling argument IMO. It reminds me of the issues that D has ("we are the better C++!!!" or even Java too). It's interesting that so many languages try to replace C. All failed, IMO. And C is still a pretty bad language. For instance, I think almost everyone would concede that crates in Rust are useful or good; C++ kind of submitted to this and has their own variant now as far as I know. C does not - or perhaps it has but almost nobody would know it.

I kind of want a language that really sits like in both camps: compiled, and scripting use. But each language seems to just fail hard in one area. Including syntax-wise. Complexity-wise too; I find Rust annoyingly complicated. Go is in many ways simpler than Rust, but it sucks in other ways. Of course there are always trade-offs either way, but I kind of want a language that can offer insane speed while having a great syntax (crystal also fails here; it is fast but the syntax is pretty bad. Why is "alias xyz abc" not working? It's so easy to support. But anyway I could go on for years here.)

[dead]

[flagged]

Zig will never be successful.