Why is Zig so cool?
This is a very confusing blog post. I found myself looking for ChatGPT markers because it doesn't make sense to say: omg zig is so much cooler than C here's why, then start listing the absolute basics of the language that are identical in most modern languages without any actual reflection why writing the same thing in a different syntax somehow makes zig superior?
In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty.
Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "something is wrong, don't know which exactly".
See: https://github.com/ziglang/zig/issues/2647#issuecomment-1444...
> I just spent way longer than I should have to debugging an issue of my project's build not working on Windows given that all I had to work with from the zig compiler was an error: AccessDenied and the build command that failed. When I finally gave up and switched to rewriting and then debugging things through Node the error that it returned was EBUSY and the specific path in question that Windows considered to be busy, which made the problem actually tractable ... I think the fact that even the compiler can't consistently implement this pattern points to it perhaps being too manual/tedious/unergonomic/difficult to expect the Zig ecosystem at large to do the same
A neat little thing I like about Zig is one of the options for installing it is via PyPI like this: https://pypi.org/project/ziglang/
pip install ziglang
cd /tmp
echo '#include <stdio.h>
int main() {
printf("Hello, World!");
return 0;
}' > hello.c
uvx --from ziglang python-zig cc /tmp/hello.c
./a.outI'm afraid this article kinda fails at at its job. It starts out with a very bold claim ("Zig is not only a new programming language, but it’s a totally new way to write programs"), but ends up listing a bunch of features that are not unique to Zig or even introduced by Zig: type inference (Invented in the late 60s, first practically implemented in the 80s), anonymous structs (C#, Go, Typescript, many ML-style languages), labeled breaks, functions that are not globally public by default...
It seems like this is written from the perspective of C/C++ and Java and perhaps a couple of traditional (dynamically typed) languages.
On the other hand, the concept that makes Zig really unique (comptime) is not touched upon at all. I would argue compile-time evaluation is not entirely new (you can look at Lisp macros back in the 60s), but the way Zig implements this feature and how it is used instead of generics is interesting enough to make Zig unique. I still feel like the claim is a bit hyperbolic, but there is a story that you can sell about Zig being unique. I wanted to read this story, but I feel like this is not it.
Zig is so cool, but C is cooler.
I like how Zig feels clear and simple to start with. I like that it gives one toolchain and makes cross compilation easy. I like that it helps people see how systems programming can feel approachable again.
I also like that C has done these things for many years. I can use different tools, link libraries, and trust that it will still work. I can depend on standards that keep improving while staying familiar.
I think Zig is exciting for what it adds today. I think C is cooler because it has proved itself everywhere and still runs the world.
I totally vibe with the intro but then the rest of the article goes on to be a showcase bits of zig.
I feel what is missing is how each feature is so cool compared to other languages.
As a language nerd zig syntax is just so cool. It doesn’t feel the need to adhere to any conventions and seems to solve the problems in the most direct and simple way.
An example of this declaring a label and referring to a label. By moving the colon to either end it makes labels instantly understood which form it is.
And then there is the runtime promises such as no hidden control flow. There are no magical @decorators or destructors. Instead we have explicit control flow like defer.
Finally there is comptime. No need to learn another macro syntax. It’s just more zig during compilation
While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers.
[1] https://research.google/pubs/secure-by-design-googles-perspe...
[2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...
The article's claim of Zig being a "totally new way to write programs" is quite mad but I'd like to make a different claim: Zig's own development is a totally new way of writing programming languages (or is at least very rare).
While I don't wholly agree with all choices made by Andrew and the Zig team, I greatly appreciate the care with which they develop features. The slow pace of deliberating over features, refining them, and removing unnecessary ones seems in sharp contrast to the development of any other langauge I'm aware of. I'm no language historian though, happy to be challenged.
Author is apparently unaware of alternatives like Ada, Object Pascal and Modula-2, where most of those "innovations" were already available.
It is kind of interesting that packaging the same ideas with a C like syntax suddenly makes them "cool", 40 years later.
I've tried writing a similar post, but I think it's a bit difficult to sound convincing when talking about why Zig is so pleasant. it's really not any one thing. it's a culmination of a lot of well made, pragmatic decisions that don't sound significant on their own. they just culminate in a development experience that feels pleasantly unique.
a few of those decisions seem radical, and I often disagreed with them.. but quite reliably, as I learned more about the decision making, and got deeper into the language, I found myself agreeing with them afterall. I had many moments of enlightenment as I dug deeper.
so anyways, if you're curious, give it an honest chance. I think it's a language and community that rewards curiosity. if you find it fits for you, awesome! luckily, if it doesn't, there's plenty of options these days (I still would like to spend some quality time with Odin)
I don't think Zig--which certainly is innovative in a number of ways--benefits from this sort of thing. Up front is a claim that it's "totally new way to write programs", but zero support is offered, and almost nothing else "meta" said about the language, other than a couple of sentences in the conclusion that are likewise inaccurate hype. I've programmed in many languages including Zig and it definitely is not a new way of programming. It imposes disciplines that are different from those of other languages, but the same is true of other languages.
The final paragraph says "This is all quite surprising" -- why so? "and let one think that many advantages previously found only in interpreted languages are gradually migrating to compiled languages in order to offer more performance" -- sure, but Zig is hardly the first ... D and Nim both have interpreters built into the compiler that allow extensive comptime computation--both of those languages have far more metalanguage facilities than Zig, in addition to many other language features that Zig lacks--which is not necessarily a fault, as it aims for a certain kind of simplicity and close-to-the-metal performance ... although both D and Nim are highly performant (both have optional garbage collection, though Nim is more advanced in making GC-free programming approachable). One thing you can say about Zig though--it compiles like a bat out of hell.
P.S. Another thing about Zig worth mentioning that came up in some comments is cross compilation. I don't think people understand how Zig is different and what an engineering feat it is (Andrew has a writeup somewhere of how it's done--it's shocking):
If you install Zig, you can now generate executables for virtually any target with just a command line argument specifying the target, regardless of what machine you installed it on. Nothing else does that--cross compilation generally requires recompiling the compiler and library to target a different architecture. Zig comes with precompiled libraries for a huge number of targets.
I noticed a comment where someone said they love Zig but they've never programmed in it--they use it to cross-compile their Nim programs. (The Nim compiler has a C code backend, and Zig has a C compiler built in, so Nim inherits instant arbitrary cross-compilation to any target via Zig).
It’s incredibly silly but I dislike zigs identifier policy. Mixing snake case and camel case for functions is cursed.
That said, amazing effort, progress and results from the ecosystem.
Bursting on the scene with amazing compilation dx, good allocator (and now io) hygiene/explicitness, and a great build system (though somewhat difficult to ramp on). I’m pretty committed to Rust but I am basically permanently zig curious at this point.
[EDIT] “hate” > “dislike”. Hate is a strong word and surely I just need to spend some time writing zig and I’d get used to it.
I love systems programming language and have worked on the Ada language for a long time. I find Zig to be incredibly underwhelming. Absolutely nothing about it is new or novel, the closest being comptime which is not actually new.
Also highly subjective but the syntax hurts my eyes.
So I’m kind of interested by an answer to the question this articles fails to answer. Why do you guys find Zig so cool ?
One of the things I like about Zig is that it pretty explicitly recognizes all the weird edge cases that exist in low-level systems code. A rather large cross-section of languages kind of pretend these cases don’t exist because addressing it would violate the aesthetic they are trying to achieve with the language. Nonetheless, these are real cases because low-level hardware and system behavior doesn’t care about aesthetics as might be expressed in a programming language.
Even C++ didn’t fully repent from this sin until around C++17. I appreciate the non-begrudging acceptance of this reality in Zig.
Why are people so obsessed with Zig when Odin has been stable, though not yet with official spec, for such a long time and used in real production for years? Is it just syntax preference or does Zig provide something amazing that I am missing? Not that I use any of them, I am not interested in manual memory management and i stick to Go. But I'm curious.
> Zig for ( 0..9 ) |i| { }
> C for (i = 0; i < 9; i++) { }
The article doesn't answer the question, it's all just about "the basics of zig" (there is nothing cool manually editing environment variables on Windows with 8 labeled steps (and 5 preliminary steps missing))
and the actual cool stuff is missing:
> with its concept of compile time execution, unfortunately not stressed enough in this article.
indeed
Zig being able to (cross)compile C and C++ feels very similar to how UV functions as a drop in replacement for pip/pip-tools. Seems like a fantastic way to gain traction in already established projects.
Why is this article even on hacker news?
Some days ago I decided to look at Zig a bit more in detail. So I skipped the usual marketing and I checked why it could be an alternative to C or Rust. Could it be?
It seems that (debug) allocators are a nice idea, however, it seems that they exist "somehow" already for C, so I wonder: why would you pick this language for your next low level program? They provide runtime checks, so you need thorough testing before you can spot use-after-free or so. It's very similar to the existing situation with c/c++ and the sanitizers, although they work a bit differently.
So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators like hardened_malloc[0] instead of starting a new programming language? It would probably be less expensive in terms of time and would help fix existing software.
> I can’t think of any other language in my 45 years long career that surprised more than Zig.
I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most.
Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros are "referentially opaque" and therefore more powerful than a referentially transparent partial evaluation - e.g. partial evaluation has no access to an argument's name), it turns out that it's powerful enough to replace not only most "reasonable" uses of macros, but also generics and interfaces. What gives Zig's partial evaluation (comptime) this power is its access to reflection.
Even when combined with reflection, partial evaluation is more pleasurable to work with than macros. In fact, to understand the program's semantics, partial evaluation can be ignored altogether (as it doesn't affect the meaning of computations). I.e. the semantics of a Zig program are the same as if it were interpreted by some language Zig' that is able to run all of Zig's partial-evaluation code (comptime) at runtime rather than at compile time.
Since it also removes the need for other specialised features (generics, interfaces) - even at the cost of an aesthetic that may not appeal to fans of those specialised features - it ends up creating a very expressive, yet surprisingly simple and easy-to-understand language (Lisps are also simple and expressive, but the use of macros makes understanding a Lisp program less easy).
Being simple and easy to understand makes code reviews easier, which may have a positive impact on correctness. The simplicity can also reduce compilation time, which may also have a positive impact on correctness.
Zig's insistence on explicitness - no overloading, no hidden control flow - which also assists reviews, may not be appropriate for a high-level language, but it's a great fit for an unabashedly low-level language, where being able to see every operation as explicit code "on the page" is important. While its designer may or may not admit this, I think Zig abandons C++'s belief that programs of all sizes and kinds will be written in the same language (hence its "zero-cost abstractions", made to give the illusion of a high-level language without its actual high-level abstraction). Developers writing low-level code lose the explicitness they need for review, while those writing high-level programs don't actually gain the level of abstraction required for a smooth program evolution that they need. That belief may have been reasonable in the eighties, but I think it has since been convincingly disproved.
Some Zig decisions surprised me in a way that made me go more "huh" than "wow", such as it having little encapsulation to speak of. In a high-level language I wouldn't have that (after years of experience with Java's wide ecosystem of libraries, we learned that we need even more and stronger encapsulation than we originally had to keep compatibility while evolving code). But perhaps this is the right choice for a low-level language where programs are expected to be smaller and with fewer dependencies (certainly shallower dependency graphs). I'm curious to see how this pans out.
Zig's terrific support for arenas also makes one of the most powerful low-level memory management techniques (that, like a tracing garbage collector, gives the developer a knob to trade off RAM usage for CPU) very accessible.
I have no idea or prediction on whether Zig will become popular, but it's certainly fascinating. And, being so remarkably easy to learn (especially if you're familiar with low-level programming), it costs little effort to give it a try.
There's at least 1 thing that Zig is better than Rust is that Zig compiler for Windows can be downloaded, unzipped then used without admin right. Rust needs msvc, which cannot be installed without admin right. It is said that Rust on Windows can use cygwin but I cannot make it work even with AI help.
> Probably the most incredible virtue of Zig compiler is its ability to compile C code. This associated with the ability to cross-compile code to be run in another architecture, different than the machine where it is was originally compiled, is already something quite different and unique.
Isn't cross compilation very, very ordinary? Inline C is cool, like C has inline ASM (for the target arch). But cross-compiling? If you built a phone app on your computer you did that as a matter of course, and there are many other common use cases.
I like the idea of the `defer `keyword - you can have automatic cleanup at the end of the scope but you have to make it obvious you are doing so, no hidden execution of anything (unlike c++ destructors).
> The @breakpoint built-in
Inserting the literal one byte instruction (on x86) - INT 3 - is the least a compiler should be able to do.
Zig is not cool. It's a mediocre new language, missing key features needed for industrial development, like destructors or overall memory safety. But for some reason it's overhyped.
A super cool feature are labeled switches: https://codeberg.org/ziglings/exercises/src/branch/main/exer...
They allow for super ergonomical coding of state machines, which is a lot of fun.
Zig structs are "modules" in themselves, apart from c like struct fields , they can have local variables, structs and functions declared and used inside of them .
in fact files in zig are just structs !
The biggest advantages of Zig for me are that everything is explicit (no hidden features like overloads or implicit conversions) and that its metaprogramming is powerful, easy to use, and easy to understand.
Unfortunately the article glosses too quickly over aspects which seem unique. For instance, I don't get what labeled breaks have to do with comp-time or why a labeled break was used in this situation over a normal function call:
>>>
Labeled breaks
Zig can do many things in compilation time. Let’s initialize an array, for example. Here, a labelled break is used. The block is labelled with an : after its name init and then a value is returned from the block with break.
>>>
The article hasn't even talked about how the language decides what an open curly brace is causing.
I've heard good things about Zig. I want to pick it up and experiment with it but at ~2% market share I find it hard to justify spending the time to learn and master it right now. It's usually much easier to find the time to learn a new language if there is a project (work or open source) that is also using it.
To author -- code sample as images is great for syntax highlight but I wanted to play with the examples and.. got stuck trying to copy the content.
(also expected tesseract to do a bit better than this:
$ wl-paste -t image/png | tesseract -l eng - -
Estimating resolution as 199
const std = @import("std");
const expect = std.testing.expect;
const Point = struct {x: i32, y: i32};
test "anonymous struct literal" {
const pt: Point = .{
x = 13,
-y = 67,
33
try expect (pt.x
try expect(pt.y
13);
67);
)Is there a decent native GUI library for Zig yet? I don't want to use bloated toolkits like GTK and Qt.
I like the simplicity and speed of Rust's eGUI. Something similar for Zig would be amazing.
I would like to see the output of the:
ldd your-zig-executable :)I am surprised Native SIMD support is not mentioned in an article with this title. Not sure if it could be applied to the sudoku example he used.
Is the inline testing good in practice? I do like the clear proximity and scope of the code being tested but I can also imagine trying to cram in all the unit tests and mocking and logging and such.
Does the feature end up feeling unused, dominating app code with test code, or do people end up finding a happy medium?
Is it cool? It seems to be in nether land between Rust and Go. Not sure what is the unique use case for Zig.
Zig doesn't seem like a bad language, but I also don't see anything to make it hands down better than Rust for systems programming. So it kind of fails my "why yet another language?" test. I don't think another language can be justified by marginal improvements.
Rust passes that test because it's categorically better than C and C++ in several ways: much better type system, safety, better modules and code reuse, etc. It's complex, but as far as I can tell most of its complexity is required to offer its level of safety guarantees in a pure systems language without a garbage collector or any kind of true dynamic typing. To make a safe systems language you need to have a very rich type system that can prove safety across a wide array of situations. Either that or you'd have to go to the other far end of the simplicity-complexity spectrum and have a language with virtually no features, which would result in very verbose code and probably a lot of boilerplate.
Zig's coolest feature to me seems like "comptime" and the lack of a weird macro side-language, which is one of Rust's anti-features that feels bolted on. Don't make me learn yet another language. Of course sophisticated macros in Rust are usually instead written in Rust itself via procedural macros, but that is more unwieldy than "comptime."
Still not enough to justify a whole new language and ecosystem though. Again: don't make me learn yet another language unless there's a big payoff.
For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?
I just discovered that you can add build-time arguments that get baked in. It's soo awesome!
A lot of comments here kind of miss the point, but that's to be expected because you can only really get it when you have the experience. Like hearing a description of a painting will not give you the same emotion as looking at it yourself.
Zig has completely changed the way I program (even outside of it). A lot of the goals and heuristics I used to have while writing code have completely changed. It's like seeing programming itself in a new way.
> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can easily say that Zig is not only a new programming language, but it’s a totally new way to write programs, in my opinion. To say it’s merely a language to replace C or C++, it’s a huge understatement.
I don't understand how the things presented in this article are surprising. Zig has several nice features shared by many modern programming languages?
zig is not cool at all, its ugly as sin, and has zero use case other than mingling with legacy c code, and who in their right mind wants to be doing that
its a hipster language, absolute insanity to use it when rust exists unless you have that very specific c related slave work to do
This article made me want to beat up Zig.
Why a new lang every day?
That inline test syntax is pretty cool; where does it come from?
>totally new way to write programs
To me it seems like a better C but not at all unique since most concepts in Zig are already present in other languages.
Zig is cool but not unique. And that is cool, too. Originality for the sake of originality doesn't add value in programming.
Top comment: this article sucks.
Then HN proceed to keep the article at the head of the front page for the day.
"This associated with the ability to cross-compile code to be run in another architecture, different than the machine where it is was originally compiled, is already something quite different and unique."
Perhaps I'm missing something but this is utterly routine. It even has the name used here: Cross-compiling.
Why would I write in Zig instead of Rust ? Only meaningful comments here
Do you need pointer arithmetic? I think that's the one feature a modern C replacement should do away with. The other being support for arithmetic with unsigned types.
Man who has only ever written C++ discovers other programming languages exist, news at 11
How on earth is it unique to compile code for different architectures? This is a solved problem since the 80s.
It basically looks like C with different syntax, im also not convinced the 0…9 implicit range is better for iteration - i prefer it explicitly for lower level languages.
Nothing against (or for) Zig, but the article author seems unfamiliar with other modern languages in common use... imagine if they saw Swift or Rust. Their mind would be utterly, utterly blown.
I like D better. And had some of the "cool" features of Zig from quite some time, such as scope(exit) which is clearer.
I don't find Zig nearly as readable as my D code, but alas, I don't do systems programming.
[dead]
[dead]
What is Zig?
Move Zig. For great justice!
I think what sets Zig apart from other low level languages is how easy it is to navigate a Zig source code. I was discouraged at the time (things probably changed now) when the best source for documentation was "read the Zig's source code". But I was impressed by how easy it was to find what I needed.
while this is due to Zig maintainers' code quality, I think a large contributing factor is the choice of syntax. As an exercise, try navigating a C, C++ and any other language source code without an IDE or LSP. things like:
- "Where did that function come from?"
- "What and where is this type?"
what do you have to do to find that out? due to the flexible ways you can declare things in C, it may take you a lot of steps to find these information. even in search, a variable and a function can share the same prefix due to the return type placement. hence why some people prefer function return types in a separate line.
Even with languages like Rust for example, finding if a type in a function parameters is an enum or struct and finding its definition can require multiple steps like search "enum Foo" or "struct Foo", in Zig i can search "const Foo" and i will immediately know what it is.
while i do hope that C gets defer and constexpr functions in the next standard or maybe better generics or enums, Zig syntax is much better to work with in my opinion.