Open-source Zig book

I'm a C/C++ developer. I write production code in MQL5 (C-like) and Go, and I use Python for research and Automation. I can work with other languages as well, but I keep asking myself: why should I learn Zig?

If I want to do system or network programming, my current stack already covers those needs — and adding Rust would probably make it even more future-proof. But Zig? This is a genuine question, because the "Zig book" doesn’t give me much insight into what are the real use cases for Zig.

If you're doing it for real-world values, keep doing that. But if you want traction, writing in a "fancy" language is almost a requirement. "A database engine written in Zig" or "A search engine written in Zig" sounds much flashier and guarantees attention. Look at this book: it is defintely an AI slop, but it stays at the top spot, and there's barely any discussion about the language itself.

Enough rant, now back on some reasons for why choosing Zig:

   - Cross platform tools with tiny binaries (Zig's built in cross compilation avoids the complex setup needed with C)
   - System utilities or daemons (explicit error handling instead of silent patterns common in C)
   - Embedded or bare metal work (predictable rules and fewer footguns than raw C)
   - Interfacing with existing C libraries (direct header import without manual binding code)
   - Build and deployment tooling (single build system that replaces Make and extra scripts)

For my personal usage, I'm working on replacing Docker builds for some Go projects that rely heavily on CGO by using `zig cc`. I'm not using the Zig language itself, but this could be considered one of its use cases.

> For my personal usage, I'm working on replacing Docker builds for some Go projects that rely heavily on CGO by using `zig cc`. I'm not using the Zig language itself, but this could be considered one of its use cases.

Hm, i can see a good use case when we want to have reproducible builds from go packages, including its C extensions. Is that your use case, or are you aiming for multi-environment support of your compiled "CGO extensions"

My take on this as someone that professionally coded in C, C++, Go, Rust, Python (and former darlings of the past) is that Zig gives you the sort of control that C does with enough niceties as to not break into other idioms like C++ and Rust does in terms of complexity. Rust "breaks" on some low level stuff when you need to deal with unsafe (another idiom) or when you need to rely on proc-macros to have a component system like Bevy does. Nothing wrong with this, is just that is hard to cover all the ground. The same happens with C++, having to grow to adapt to cover a lot of ground it ended up with lots of features and also with some complexity burden.

In my experience with Zig, you have the feeling of thinking more about systems engineering using the language to help you implement that without resorting to all sort of language idioms and complexity. It feels more intuitive in way giving it tries to stay simple and get out of your way. Its a more "unsurprising" programming language in terms of what you end up getting after you code into it, in terms of understanding exactly how the code will run.

In terms of ecosystem, lets say you have Java lunch, C lunch and C++ lunch (established languages) in their domains. Go is eating some Java(C#, etc..) lunch and in smaller domains some C++ lunch. Rust is in the same heavy weight category as Go, but it can eat more C++ lunch than Go ever could.

Now Zig will be able to compete in ways that it can really be an alternative to C core values, which other programming languages failed to achieve. So it will be aimed at things C and C++ are doing now and where Go and Rust wont be good candidates.

If you used Rust long enough you can see that while it can cover almost all ground its not a good fit for lower level stuff or at least not without some compromises either in performance or complexity (affecting productivity). So its more in the same family as C++ in terms of what you pay for (again nothing wrong with that, is just that some complex codebases will need a good amount of man-hours effort in the same line as C++ does).

Don't get me wrong, Rust can be good at low level stuff too, is just that some of its choices make you as a developer pay a price for those niceties when you need to get your hands dirty in specific domains.

With Zig you fell more focused on the machine with less abstractions as in C but with enough goodies that can make even the most die-hard C developer think about using it (something C++ and Rust never managed to do it).

So i think Zig will have its place in the sun as Rust does. But I see Rust taking more the place where Java used to be (together with Go) + some things that were made in C++ where Zig will be more focused on system and low level stuff.

Modern C++ will still be around, but Rust and Zig will used more and more where languages like C and C++ used to be the only real contenders, which is quite good in my POV.

What will happen is that Rust and Zig programmers might overlap and offer tools in the same area (see Bun and Deno for instance) but the tools will excel on their own way and with time it will be more clear into which domain Rust and Zig are better at.

My use cases similar to this https://blog.afoolishmanifesto.com/posts/golang-zig-cross-co...

need to bundle a lot of C libraries, some using dynamic linking and some using static linking, and I need to deploy them on different operating systems, including some that are difficult to work with like RHEL. Right now the builds are slow because I use a separate Dockerfile for each platform and then copy the binary back to the host. With Zig CC I could build binaries for different platforms and architectures without using Docker.

thank you for your detailed answer. I found another great discussion around Zig here https://news.ycombinator.com/item?id=26374647