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.

▲ tamnd an hour ago | parent [-]

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.

	▲	pelasaco an hour ago \| parent [-]
		> 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"