Theory vs. Practice

First, like many others before it, Zig claims to be "better than C". So we will go through its claims and my view on their value.

Second, the founder seems to have a passion for performance, but their project goals might need a better defined focus: beyond getting paid to use and rewrite existing tools, what are they really trying to achieve – and where is the value for users?

Is it worth spending time on it? If not, why?
I will try to address all these points in this article.

What's New in Zig?

They have used LLVM to interface Zig to C or Go (and probably many other languages) via a machine-code abstraction layer (LLVM IR), like the C-to-JS WebAssembly did it to let JS inherit from C libraries and even whole applications (games and even OSes running in our Web browsers...).

Handy... if you really have to deal with different platforms and mix code from different programming languages (the recipe for disaster, unless you love chasing deeply obfuscated bugs).

So, What's New in the Zig programming language?

They claim "Zig lets you start debugging your program rather than your programming language knowledge" since "Zig is more readable and intuitive than C"... but a mere Zig prototype (taken from Wikipedia) takes 112 characters and C 56 (half of Zig's code):

C

const char *repeat(const char *original, size_t times); // 56 characters (without this comment)

Zig

fn repeat(allocator: std.mem.Allocator, original: []const u8, times: usize)
   std.mem.Allocator.Error![]const u8; // 112 characters (without this comment)

Obviously, C is simpler than Zig which readability (visibly inspired by the verbose C++) is lower and learning curve higher.

It is also revealing that some of the alleged Zig progresses are just renamed variable types (char to u8, size_t to usize), using a C feature called typedef (1976, C version 6) – leading to even more concise and readable code as compared to Zig (2016):

C

const u8 *repeat(const u8 *original, ulong times); // 50 characters with the G-WAN 2009 types

Starting with such a fallacy is not a good sign, and the promised "progress for the masses" is absent. But Zig presents a much longer list of arguments so, to be fair, let's weight them one by one.

Reasons why Zig is a better language than C (according to Zig)

Thought: ...to do things that macros were not designed for (hence their side effects). Use inline functions if macros do not fit the task. Just keep in mind that macros can do things that functions cannot do. Macros are not a shameful vestige of the past – the fact that you don't see how they can be useful just reveals your limitations (if you are afraid of a knife, take a spoon).

Thought: C string functions cause problems when misused (most of the time people should rather use the faster and safer memxxx(pointer, length) functions instead of the strxxx(pointer) functions).
C gives you the choice – it does not force you to do anything. But, even complete careless people are safe with C strings when using SLIMalloc (2020), written in C, and granting app+libraries "memory-safety" since 2023 (without a Rust straitjacket).

Thought: Fallacy. That's called "cross-compiling", and it exists for decades, for C and other languages. The Zig toolset does it with LLVM (2003), which existed long before Zig (2016).

Thought: NO. Go and Zig hide slow and inefficient libraries behind a convoluted syntax (which only purpose is to "lock-in" users by being incompatible with C). I could not have written G-WAN in Go or Zig without having to rewrite Go and Zig entirely – breaking their compatibility at the syntactic and grammatical levels.
C allowed me to rewrite many critical LibC parts without breaking the 50-year old C syntax. C makes you free to give your best – others want to keep you confused (via pointless complexity), small, vulnerable, dependent and obedient. See the difference?

Thought: False. Since 2009 G-WAN written in C uses defer. I am not sure how Zig does it, but there are several ways to do it in C. Since 2020, SLIMalloc uses defer to make sure that free(ptr); enforces ptr = NULL; once freed (no more double-free and use-after-free malloc errors – the very same errors that, we are told, cannot be fixed in GOOGLE Chrome).

Thought: I do it with C in G-WAN since 2009 – for example, to get automatically a version number as a static const char version[]; string under the format of my choice, with C preprocessor macros.
C can do more of this with macros (or compiler builtins) to encapsulate variables, functions, etc. so I won't switch to another language for such (rarely used) features (that could be added to any programming language via its compiler).

Thought: G-WAN asm/C/C++ servlets (2009) did this with #pragma include, way before Zig (2016).

Thought: To use pointer arithmetic, Zig forces users to create pointers variables from the original Zig types... do the arithmetic, and then go back to the original Zig types (what a progress – that's clunky and unreadable!).
In contrast, SLIMalloc (2020) does all this transparently for C/C++ (and their derivatives like PHP, etc.). Programmers can't make mistakes because SLIMalloc automatically enforces the buffer boundaries – and it optionally documents any violations in real-time (while the unharmed program keeps running instead of crashing).

Thought: The old standard C function alloca() does exactly this – without the need for a defer call.

Thought: Many C memory allocators (like SLIMalloc) do this (often with a better granularity, like with per-thread and per-task memory pools) with and without debug information. Create new libraries, not new languages.

I have the feeling that, while trying to collect every possible argument that may help to promote Zig as "a better language", they have missed the point.

The point is about making programming easier, safer, and more efficient (not to force everyone to learn a new syntax while all these features are already there [in C, or C libraries like SLIMalloc, or C applications like G-WAN] or could easily be added to all compilers).

Reasons why Zig is a better language than C++ (according to Zig)

Thought: Some ACM/Turing award winners are a bit more specific about it... maybe because they understood what's wrong with C++ (considering it as an "insult to the human brain" – most probably the only reason why it was funded in the first place).

Reasons why Zig is a better language than Rust (according to Zig)

Thought: Unlike C, but very much like C++, Java, JS, C#, Go... and Zig.

Thought: Unlike C (read the SLIMalloc II paper). And, by the way, Zig is not memory-safe, so why adopt an inferior language than C (the kind allowing the making of libraries like SLIMalloc and applications like G-WAN)?

Thought: Zig is twice more verbose than C – that's not readability. And, again, abstractions should be a matter of APIs, not programming language syntax.

Reasons why Zig is a better language than Go (according to Zig)

Thought: Unlike C, but very much like the "more modern" languages written by people claiming to "know-better" than everyone. I don't claim that I "know-better" than Brian Kernighan & Dennis Ritchie: I am grateful for their fundamental achievements, and I try to honor the same spirit by adding useful features to C without breaking it – the proper way, via C libraries.

Thought: Their goal is to borrow as much as they can (like SQLite written in C), but to avoid giving anything back to C, in order to convince people that "Go obsoletes C" (despite G-WAN being faster and safer than all other servers – whatever their programming language).

The only way to demonstrate that you are right is to do much, much better than all others (in features, performance and security).

UPDATE: The Views of the Undisputable Expert who coined the term "Unix"

At the time I wrote this article, I was not aware of a similar stance in reply to someone asking if Rust will replace C. Here is the opinion of Brian Kernighan (co-author of "The C Programming Language" book with Dennis Ritchie, inventor of the C language):

See? My views were, probably for the same reasons, aligned with the ones of the still-alive C language co-author:

Brian Kernighan immediately listed arcane, pointless complexity, agonizingly-slow execution times and ever-changing syntax (outdating its own official documentation!) – wasting days of your time while, he said, writing a C program would take 5 minutes.

Worse, that's where all the money, hype, media exposure, and academic time (courtesy of the taxpayer) goes. Rust is sponsored by the "Rust Foundation", which includes founding members such as... the GAFAM.
If that does not make you think, nothing will.