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?
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);

Zig

fn repeat(allocator: std.mem.Allocator, original: []const u8, times: usize)
   std.mem.Allocator.Error![]const u8;

Obviously, C is much simpler than Zig which readability (visibly inspired by C++) is much lower and learning curve much higher.
The promised "progress for the masses" is absent. Since Zig presents a much longer list of arguments, 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 by pointless conplexity, 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 double free).

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++.

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).

The Holly War against Simplicity and Efficiency

There's a common "mistake" made by all the programming language authors I have seen after C (I learned programming in asm at a time C compilers were not available on the platforms I could afford to access). After C, like if C was too simple to use, C++ started this disastrous trend of stacking libraries for every possible case, without regard to coherence or quality. This approach misses THE point:

C did not last half a century because it was constantly funded. Its competitors received much more funding (and media exposure). And if C did not evolve much as a programming language, that's a fact that I consider as the indisputable evidence of its fitness to the task: simple, efficient, portable... and incredibly more capable than anything made since then.

Zig, like all the others claiming to replace C, enforces libraries INTO THE LANGUAGE SYNTAX (preventing you from doing better than the authors of the standard library). Note to the authors: PREVENTING PROGRESS IS NOT AN IMPROVEMENT.

When features rely on (arbitrarily ever-changing) obscure incantations, either you learn these new ephemeral sterile forms every single time they mutate, or you will no longer be able to use them! That's planned obsolescence (of your working tools).

The pursued goal is to consume your brains' time in the vain pursuit of ever-vanishing ghosts (while they prepare a new generation of crappy abstractions... to stay in charge of what they call their "leadership").

In contrast, C provides stable, easier to understand APIs... that you can override with your own faster/safer code.

The implementation freedom is crucial because its absence kills the claim that "Zig is low-level, giving you full control of the machine". Like C++, Java/C#, JS, Go and Rust, Zig failed to do what C did properly 50 years ago.

How do you think you can build on the basis of ever-obsoleted languages (and OSes)? You cannot. And that's the pursued goal of the ones at the switch. I am not saying that the Zig founder is consciously planning to do it wrong, I think that he believes copying BigTech will make him win some points. No, you're not. You only prove that you don't understand what matters for programming: simplicity and stability are paramount.

This so-deceptively named "modernity" is great – if you want to ditch all your work every 2 years – and restart from scratch with tools that are so different that your past experience has been made irrelevant.

Only a foolish man would build his house on the sand.

This relentless destruction of engineering skills (via the constant funding of malformed newborn standards imposed to the world) serves a purpose: abolishing everything that works to replace it with chaos is the only certain way to lead to the destruction of our economy (giving full power to the very few creating money out of thin air – the only ones able to survive any catastrophic event).

Among the rest of us, not many want to be ruined (intellectually and financially), so:

• Write C libraries – the best ones will stand as unique references (for you and others).
• Don't create yet another half-backed programming language aimed at spreading more destruction and self-helplessness.

Programming languages and OSes should be stable for decades – not constantly break everything for hyped "coolness and fashion".

The Method used for the Destruction of Value

Zig seems to be very much based on prior GAFAM works: Microsoft-sponsored C++ (the largest language ever made – that's not a compliment) and Google Go (with ambitious initial promises followed by poor usability and performance). These out-of-control degenerate genetic experiments are already obsoleted by "Carbon" from Google – the new annihilator (maker of HTTP/2 and HTTP/3... to obsolete an immensely simpler, safer and long-lasting HTTP/1.1).

On the bright side, Zig says it will try to unify programming languages (via LLVM) rather than make a new one incompatible with all others (like Google Go did it). I find the goal admirable, but I would do it for compilers (like LLVM started to do it) rather than by inventing yet another cabalistic programming language syntax.

Confusion of goals and perfection of means seems, in my opinion, to characterize our age.
Albert Einstein (1879-1955)

Conclusion

To the world of finance (micro-managing the GAFAM and governments):

Can we keep the old ways to do new things (for the sake of letting progress happen) instead of pay for ever-increasingly slower and more complex new ways to do old things (designed to prevent progress from happening)?

There are too many institutional players interested in restricting, controlling, and directing ordinary people's ability to make, access, and share knowledge and creative works online.
Leah Lievrouw, professor of information studies, University of California

This might help to explain why the United Stated and Europe are losing at the research, industrial and therefore economic games, because, under other jurisdictions, the guardians of the Temple don't censor and sabotage their own economy, technology and population – for the preservation, at any cost, of "elite" control (established and maintained via the private monetary creation and allocation and the monopoly of violence).

As history as shown (all the U.S. and European presidents deploying green-backs, that is a currency backed by public money-creation rather than private money-creation, have been the target of assassination attempts), there are better ways to manage a country, but is implies to dilute the power granted by this "exorbitant privilege" (robbed from the States by a very few lawless and merciless private individuals, via corruption and murder).

Never before mankind has been so close to negating its own good by destroying itself (via State-funded military weapons such as pandemics, theatrical and clandestine wars, climate engineering – all used at the same time!), so the only real question is: if this self-proclaimed "elite" cannot do any better than destroying what it so furiously wants to own, why not try a less certainly self-defeating option?