Why Zig When There Is Already C++, D, and Rust?

I don&#x27;t know why this article keeps showing up on HN every other year but since it&#x27;s up, I took the time to read it and fix all the outdated facts.<p>Notably, when it was written before there was not a package manager available. Now there is, so I rewrote that section. It should finish deploying in a couple minutes.

I am a big rust fan, but I&#x27;ll say I don&#x27;t think a language should need to justify its existence and whether it&#x27;s redundant or not. Zig exists because its developers and users want it to. People like coding in it, that&#x27;s all the justification it needs.<p>I&#x27;m glad people make new programming languages without asking permission from the world whether it provides enough value to exist.<p>(TBC, I realize this page is more about answering questions about differences between zig and other languages, emphasizing its strengths, I just think the framing of the question is unfortunate)

I&#x27;m confused by &quot;No hidden control flow&quot;<p>To me control flow is &quot;if&quot;, &quot;switch&quot;, &quot;?:&quot;, etc. What article describes are abstractions. Abstractions are not bad. They, just like anything else, can be abused. Maybe one may argue are easy to abuse or tend to be abused. But &quot;Zig has no abstractions&quot; is hardly a selling point.<p>On the other hard there are statements like &quot;defer&quot; and &quot;try&quot; which actually are very hidden and unusual control flow statements. Why the naming? Who the hell knows. I see try, I look for catch&#x2F;except&#x2F;finally, but there are none. Try in Zig means something else. &quot;defer&quot; is literally &quot;try&#x2F;finally&quot;, but less explicit about the scope.<p>&quot;A Portable Language for Libraries&quot; &quot;A Package Manager and Build System for Existing Projects&quot; &quot;drop-in GCC&#x2F;Clang command line compatibility with zig cc&quot;<p>Is it still so after ditching LLVM?

Lack of destructors&#x2F;RAII is the deal breaker for me. I know that this causes a function call to be made when a variable goes out of scope, which is &quot;hidden control flow&quot; and therefore banned by the language design.

&gt; If you never initialize a heap allocator, you can be confident your program will not heap allocate.<p>This is true for the standard library, where I can trust that no hidden allocations will be made. If I pull in a third party package, nothing guarantees that that lib won&#x27;t init a new `std.heap.GeneralPurposeAllocator(...)`, right?

This page seems only halfway there. These are not quite terminal arguments. No hidden allocations, standard lib is optional, simplicity - all cool! But the question is, when are those the right tradeoffs?<p>For example, I could see these being attractive in embedded work. I could see the simplicity becoming a headache in other contexts, like making abstracted all-purpose numerical libraries a la Eigen.<p>Maybe I am wrong about those particulars! But I would like the arguments completed: Zig has X distinctive features, <i>which you should prefer if you do Y</i>.<p>This is relevant to my interests right now: I am working on scaling up some scientific algorithms for astronomy research which have been well prototyped in Python, but which need to be faster. I am currently, unhappily, doing my work in C++ after abandoning Rust for being too immature in its CUDA and SIMD support, while also feeling pretty complex. Would Zig do well enough for me? I want a little more ink on the page to help me think this through.

&gt; Examples of hidden allocations:<p>&gt; Go’s defer allocates memory to a function-local stack.<p>Not really hidden if there&#x27;s keyword indicating it&#x27;s happening, no? I guess you could argue that &quot;defer&quot; isn&#x27;t called &quot;defer_and_allocate&quot;, but on the other hand, the docs make it clear that it allocates.

The lack of operator overloading is a bummer for mathematics code, eg involving matrices, vectors, tensors, complex numbers etc.

Does the requirement to pass around an allocator end up causing a &quot;what color is your function&quot; problem?

There’s some tension between the first section about what Zig guarantees and later sections about having great interoperability with C. If you have a lot of C dependencies because it’s easy, what guarantees can you have? Doesn’t the C code need a system allocator?<p>Maybe this could be resolved by distinguishing between writing new libraries in Zig and building applications. New libraries can be clean and reusable even if the applications are a hodgepodge of dependencies.<p>For libraries, reuse versus rewrite is still a question. With any new language ecosystem that provides new guarantees, there’s a drive to build a new set of libraries within the ecosystem to get those guarantees. This is an enormous effort. An end goal of making libraries more reusable, to stop rewriting them, seems in tension with the means of getting there, which is by rewriting rather than reusing libraries.<p>Also, if you write a library in Zig, aren’t you limiting your audience?

The standard library being designed to allow freestanding binaries makes Zig a much better language for systems software such as kernels, EFI applications, etc. than Rust.<p>Rust&#x27;s addition of operator overloading is also a perplexingly bad decision. I don&#x27;t think there is a single worse design decision in C++ or Rust than allowing someone to redefine what + means on some arbitrary type.

I use D, and there is nothing in that article that&#x27;s convincing enough for me to switch<p><pre><code> $ time make build-game real 0m0.387s user 0m0.309s sys 0m0.077s $ time make build-sgame real 0m0.334s user 0m0.245s sys 0m0.057s </code></pre> Complete full rebuilds of my game and game server on linux (on windows it is the double)

I think the other important thing would be who is using zig in production besides Bun &amp; TigerBeetle ?

If there is no string concatenation operator (for run time), how do you concatenate strings at run time with Zig?<p>Depends on what you work on, I guess, but in my area of expertise string operations like concatenation are bread-and-butter.

I don&#x27;t really agree about the simplicity: to me, C3 feels like it&#x27;s closer to C, and C is just simpler to learn.<p>Although among those new statically compiled languages, zig would be my favorite choice.<p>I just wish it was just even simpler.

Because D&#x27;s tooling and ergonomics are awful. But how are Zigs?

&gt; C++, D, and Go have throw&#x2F;catch exceptions<p>I believe Go does not.

These discussions usually focus on features. How about a simple &quot;because you tried Zig and you enjoyed writing it more than language X&quot;?

Zig : because language design is better when encouraged by diversity, as so many things are.

I read a point about lowering <i>activation energy</i> on JDK website about making language more approachable. Though Zig is lower level language and much of use for typical enterprise devs like me it does have vibe of low activation energy.<p>I feel a lot of useful software will be written in Zig once it is picked by young&#x2F;upcoming clever developers.

Only C++, D and Rust?<p>What about Ada, Pascal, Swift, Nim, Crystal, Carbon, Jai, etc.

A better question is, why zig when you could use jai instead?