So unless you work in another domain where you do a lot of low level programming, then every time you drop down you will be out of practice. This favors using a simpler low level language, with low friction for integration. Rust and C++ don't handle being used infrequently, but C with it's simpler standard library and syntax fits this nicely. But it doesn't have things you expect for a modern programming language, and it is also has a lot of dangerous footguns that are easy to forget if you are out of practice
In comes Zig. It's low level, comes with it's own toolchain that makes it pleasant to work with, easy to cross compile, has more safety features built in that C, but is not overly complicated. The code tends to be more verbose, but also more straightforward. So it's a perfect language to pair, when you know you won't be able to do everything in a high level language.
For me that's what seals the deal. I'd argue that Odin has a nicer syntax, but there is a reason that tools like cargo-zigbuild^1 exists. The fact projects not related to Zig are willing to ship Zig toolchains to make lives easier is a testament to how seriously Zig takes this.
On the other hand if safe Rust is an option that's way more handholding than you're getting in Zig. Lots of "Whoops I forgot" mistakes won't even compile in safe Rust because it couldn't see why they're OK and that's required but in Zig now you've written a bug.
It's running slow so I profile it and I see my math function in pure Dart (or whatever language you are writing in) is the hot spot, and pressures the garbage collector too much, so I rewrite the function in a lower level language that doesn't have as much overhead, to speed things up. Then I just call it from the higher level language through the FFI.
The benefit of Zig is the syntax is simple, and the build steps are simple, so it doesn't slow down app development too much
> To go deeper, I think I need to dig into a systems language
Most of such code is still written in C.
But honestly, if you just need to squeeze a little bit more performance, you should check the non-GC part of C# first (ArrayPool, Span, stackalloc).
Zig will be much easier to learn than Rust, but it's worth noting that it's syntactically very unstable between releases (there were some huge changes between 0.15.2 and 0.16 to anything involving IO).
It's really hard to predict what you'll actually use professionally in the future or what's going to be popular in ten years, but some of the greatest value comes from just learning a huge variety of topics.
I'm a firm believer in prioritising enjoyment over utility, and I've always found that utility has flowed backwards from the enjoyment. And even if it doesn't, you've had a good time and found yourself richer for it!
I don't think in your shoes I'd prioritize learning Zig for any of these domains, though, for a few reasons:
* It's not a pre-req for understanding some existing corpus of important software (which is a big reason for C and C++ in 2026) or the language of choice for some current hot domain (as Python is for AI).
* It's not memory-safe, which (whether via GC or Rust's borrow checker) is increasingly viewed as a critical security attribute.
* It's not stable yet, so I'd expect a certain amount of running to keep in place both in your learning and in avoiding bitrot in anything you write in it.
* From the outside, the community seems strangely hostile as well as elitist.
A few I might suggest instead: Rust (both as a language I personally like and as the most different from the ones you've already touched), Go (which is a good choice for employability), SQL (maybe you already know this one if you're doing CRUD stuff but you didn't list it), bash, and more Python and/or TypeScript.
Zig is a very interesting and well built language, but it is also niche, unstable and not offering radical improvements over C.
C, as the foundation of all modern kernels and system tools, among many other things, is extremely unlikely to go away soon.
Everything you do in Zig can be done almost in the same way in C or C++.
I would say the real value of Zig is in the standard library that is more modern and arguably better.
Can you do this in C?
I am generally against the idea of language support for meta-programming, even using C macros or C++ templates.
I do a lot of meta-programming/codegen with external tooling.
That's not an answer. There's a reason why you can't do it in C, and the reason is "the stdlib is poorly designed". No amount of linting can get you around that.
A new modern C standard library would be a very good thing. But I am ok writing my own, tailored for my own needs and style.
All of that is investment, and not all languages pay off that investment.
https://www.youtube.com/watch?v=iqddnwKF8HQ
Personal thoughts: I think Zig will become more stable once 1.0 tag released. Currently I cant find a fix to my error in net. But the folks on Zig Discord server helping me out.
With this in mind: Does anyone here program in Zig, or know someone who does who is not a current C (or C++) programmer?
Most recently I have used zig for:
Linux USB driver for a proprietary industrial digital camera that claude hacked the protocol for (I usbpcap'ped it), bound into an embedded Elixir-Nerves biology workstation. Same workstation has a libtoupcap digital camera for a microscope camera also mounted (here I use zig for the dlload boundary with elixir). The proprietary system I am running it on ironically won't work with windows anymore because the proprietary software it shipped with chokes when there are two cameras attached.
I ship zigler, the embed-zig-in-elixir library. I keep finding more and more uses for it!
Having been exposed to Java < 5 (before generics) Arrays felt somewhat like JavaScript or PHP3. It's a lot more ergonomic today.
But there are still many remnants (like null refs, despite Option<>) that are easiest understood by tracing back Java's historical roots.
I think Zig does, specifically because of its build system and it's C interopt story. Plus Zig has the added advantage that learning it teaches you about how the computer works, how memory gets laid out, etc. So even if it never gets wide adoption the skills are highly transferable.
Just because people don't like this doesn't mean it's not true.
C will almost certainly adopt defer in the next revision standard. C++ (via RAII + scoped classes) already effectively has defer.
But the fact that it's unsafe means it's effectively unadoptable, no reason not to use C inplace of it.