As someone who used C as main language, I've switched to zig. It's the only language that tries to be "better C", and not another C++. Comptime being like Nim where it's not entirely own language is also plus. I'd say it excels at general purpose system programming, and especially if you need to work with memory in detailed way (rust makes this very annoying and hard).
- comptime, so writing compile time evaluating code, without introducing its own meta language like macros or templates.
- very solid build system (the build config file(s) are written in zig so you dont have to learn another language for the build system (looking at you, makefile)) that has crosscompilation builtin (with one compiler flag)
- language level errors, like, errors as first class citizens. forces you to handle errors, but without much mental or syntactic overhead (you can re-throw them with `try myfunction()`), also results in a unified interface
- no implicit conversions
- looks high-level (modern sytnax that is easy(ish) to parse) but as low level (or lower) than C, no abstractions that hide details you need to know about when programming (similar to C)
- C interop, so you can just add zig source files to a C project and compile it all with the zig toolchain. Zig can also parse c headers and source files and convert them, so you can include c headers and just start calling functions from there. For example, using SDL is as simple as pointing the toolchain to the SDL headers and .so file, and the sdl headers will be translated to zig on the fly so you can start with SDL.SDL_CreateWindow right away.
Just to name one: compile time code execution. It eliminates the need for a separate macro language and provides Zig zero cost generic types.
Not to mention memory leak detection, crazy fast compilation times, slices and a built in C compiler so your code can seamlessly integrate with an existing C code base (seriously no wrapper needed).
Zig is really really awesome. The only thing holding it back from mass adoption right now is that it's not finished yet, and that shows in the minimal documentation. That said, if you're comfortable tinkering, it's completely capable of production uses (and is already used in production in various companies).
This is just not true and it's the reason #1 I am not using Zig.
To give you some numbers, ZLS is a reasonably sized project (around 62k LOC of Zig) and on my very beefy machine it takes 14 seconds to build in debug mode and 78 seconds to build in release mode.
Because of the "single compilation unit" approach that Zig uses this means you are paying for that very same time regardless of where you modify your program.. so basically clean rebuild time is equal to simple modification time.
As a comparison my >100k LOC game in Rust takes less than 10s to build in release mode for modifications that happen not too far down the crate hierarchy.
So yeah, be for whatever reason you want (LLVM, no incremental builds and so on) as for today Zig is not even close to having "crazy fast compilation times".
True, current compilation times with Zig are not yet optimal. We're getting there though. As our own custom backends become complete enough we will be able to enable incremental compilation and the aim is for instant rebuilds of arbitrarily large projects.
Possibly the thing that makes C be C is that there is only one C. It is the single lingua franca of "one notch up from assembly". I would argue any language that wants to be a better C has to accept the challenge of being available on any platform, existing or future, any architecture, suitable for any bare metal use case, and it has to want to be the single obvious go-to choice. That's what it means to step into the ring of "better C" candidates. A lot of languages might offer pointers, manual memory allocation, no runtime, etc. That's cool and that gets you close to the space. But if you want to be a better C, then the bar is much higher: ubiquity.
IMHO one of C's strong points is the ubiquity of non-standard compiler extensions, C with Clang extensions is much more "powerful" than standard C, personally I see C as a collection of closely related languages with a common standardized core, and you can basically pick and choose how portabel (between compilers) you want to be versus using compiler-specific extensions for low level optimization work (and in a twisted way, Zig is also a very remote member of that language family because it integrates so well with C).
> "one notch up from assembly"
C is actually a high-level language, it's only low-level when compared to other high-level languages, but much closer to those than to assembly. Arguably Zig is in some places even lower-level than C because it's stricter where C has more "wiggle room" (for instance when it comes to implicit type conversions where Zig is extremely strict).
> being available on any platform, existing or future, any architecture, suitable for any bare metal use case
Zig has a pretty good shot at that requirement, it has a good bootstrapping story, and for the worst case it has (or will have) a C and LLVM (bitcode) backend.
For me personnally, Zig will most likely never completely replace C, but instead will augment it. I expect that most of my projects will be a mix of C, C++, ObjC and Zig (and Zig makes it easy to integrate all those languages into a single project).
