Why is Zig so cool? (nilostolte.github.io)

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

That inline test syntax is pretty cool; where does it come from?

I would like to see the output of the:

    ldd your-zig-executable :)

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

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

Which means you don't even have to install it separately to try it out via uvx. If you have uv installed already try this:

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

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

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)

Is it cool? It seems to be in nether land between Rust and Go. Not sure what is the unique use case for Zig.

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?

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.

[dead]

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

Move Zig. For great justice!

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.

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

)

What is Zig?

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.

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

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?

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.

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

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.

https://survey.stackoverflow.co/2025/technology