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.

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"