Skip to content(if available)orjump to list(if available)

Why is Zig so Cool?

Why is Zig so Cool?

27 comments

·November 7, 2025

simonw

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

pyrolistical

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

badtuple

I was also curious what direction the article was going to take. The showcase is cool, and the features you mentioned are cool. But for me, Zig is cool is because all the pieces simply fit together with essentially no redundancy or overloading. You learn the constructs and they just compose as you expect. There's one feature I'd personally like added, but there's nothing actually _missing_. Coding in it quickly felt like using a tool I'd used for years, and that's special.

Zig's big feature imo is just the relative absence of warts in the core language. I really don't know how to communicate that in an article. You kind of just have to build something in it.

rvrb

out of curiosity, what feature do you want?

rvrb

matklad did it justice in his post here, in my opinion

https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html

null

[deleted]

rvrb

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)

meisel

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?

rvrb

the answer I've seen when it has been brought up before is that (for allocators) there is not a practical impact on performance. for code bloat, I'm not sure what you mean exactly; the allocator interface is implemented via a VTable, and the impact on binary size is pretty minimal. you're also not really creating more than a couple of allocators in an application (typically a general purpose allocator, and maybe an arena allocator that wraps it in specific scenarios).

for IO, here are some relevant paragraphs:

  The new Io interface is non-generic and uses a vtable for dispatching function calls to a concrete implementation. This has the upside of reducing code bloat, but virtual calls do have a performance penalty at runtime. In release builds the optimizer can de-virtualize function calls but it’s not guaranteed.
  
  ...
  
  A side effect of proposal #23367, which is needed for determining upper bound stack size, is guaranteed de-virtualization when there is only one Io implementation being used (also in debug builds!).
https://kristoff.it/blog/zig-new-async-io/

https://github.com/ziglang/zig/issues/23367

hamandcheese

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.

fastball

Strangler fig

pron

> 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 (which also assists reviews) may not be appropriate for a high-level language, but it's a great fit for an unashamedly 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 acknowledge 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 "huh" rather than "wow", such as it having little encapsulation to speak of. In a high-level language I absolutely 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.

I have no idea or prediction on whether or not 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.

sreekotay

This is the real answer (amongst other goodness) - this one is well executed and differentiated

Every language at scale needs a preprocessor (look at the “use server” and “use gpu” silliness happening in TS) - why is it not the the same as the language you use?

ufko_org

I would like to see the output of the:

    ldd your-zig-executable :)

alexrp

Zig defaults to statically linking musl when targeting Linux, so the output will not be very interesting unless you target dynamic musl, or glibc, or FreeBSD/NetBSD.

didip

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

jorangreef

We could not have written TigerBeetle, at least not the way it is, without Zig:

https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...

rvrb

not being a direct competitor to either of these already existing languages is exactly why it is interesting!

KerrAvon

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.

pphysch

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

ForHackernews

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

chrisco255

I feel like the article didn't really hit on the big ones: comptime functions, no hidden control flow, elegant defaults, safe buffers, etc.

What Zig really does is make systems programming more accessible. Rust is great, but its guarantees of memory safety come with a learning curve that demands mastering lifetimes and generics and macros and a complex trait system. Zig is in that class of programming languages like C, C++, and Rust, and unlike Golang, C#, Java, Python, JS, etc that have built-in garbage collection.

The explicit control flow allows you as a developer to avoid some optimizations done in Rust (or common in 3rd party libraries) that can bloat binary sizes. This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether.

The built-in C/C++ compiler and language features for interacting with C code easily also ensures that devs have access to a mature ecosystem despite the language being young.

My experience with Zig so far has been pleasurable. The main downside to the language has been the churn between minor versions (language is still pre-1.0 so makes perfect sense, but still). That being said, I like Zig's new approach to explicit async I/O that parallels how the language treats Allocators. It feels like the correct way to do it and allows developers again the flexibility to control how async and concurrency is handled (can choose single-threaded event loop or multi-threaded pool quite easily).

raincole

> One may wonder how the compiler discovers the variable type. The type in this case is *inferred* by the initialization.

That the author feels the need to emphasize this means either that they haven't paid attention to modern languages for a very long time, or this article is for people who haven't paid attention to modern languages for a very long time.

Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature.

> One is Zig’s robustness. In the case of the shift operation no wrong behavior is allowed and the situation is caught at execution time, as has been shown.

Panicking at runtime is better than just silently overflowing, but I don't know if it's the best example to show the 'robustness' of a language...

blahgeek

This. Is Zig an interesting language? Yes sure. But “a totally new way to write programs”? No, I don’t see a single feature that is not found in any other programming languages.

fuzzy_biscuit

Of which, perhaps, the author isn't aware? Perhaps the author has very narrow experience in programming languages.

Or it's hyperbolic.

moralestapia

>Perhaps the author has very narrow experience in programming languages.

I got that impression as well.

Xi's impressed about types being optional because they can be inferred.

That's ... hardly a novelty ...

null

[deleted]