What is the use case for Zig?
I’m of the impression that C will never die.
There are just too many benefits, not least developer velocity and readability.
Zig is also very approachable to anyone who is familiar with TypeScript, in a way that C isn't. This means more of your team can get excited and get involved, at least in terms of reading the code.
And with Zig, where you have to spend a little extra maintenance time paying for the language being pre 1.0, that's still nothing compared to the upfront and long-lived costs associated with C. You can develop so much faster in Zig compared to C, that you're ahead even pre 1.0.
const print = @import("std").debug.print;
How does Zig compare to Nim?
Does Zig have a future in games programming? I feel games programming is the ultimate test, to validate the true success of a programming language.
I do like that Zig compiles to LLVM. Although this in itself will exact a minor performance penalty, in exchange for wider CPU coverage.
Nim transpiles its code down to C, and I’m not certain how that will play out. As you’re now writing your new language on an already somewhat buggy language.
But this does give Nim the possible speed advantage, of getting the code compiled closer to the metal, whereas Zig will compile to the intermedia LLVM layer.
It's going to start compiling to zig IR soon (if it doesn't already), and zig IR will be translated to LLVM IR or fed into zigc. So I think the recommended development cycle will be - use zigc for fast iteration on localdev, then when releasing, use slower LLVM for extra optimization passes and also for cross-compilation.
> gamedev
I think the highest interest in zig is currently gamedev, but there are SO MANY uses for zig.
If I may be permitted some shameless self-promotion, zig is pretty awesome: https://www.youtube.com/watch?v=l848TOmI6LI
This is actually a surprisingly underserved field. There's relly very few language that actually tries to be just C but better.
Go: Uses garbage collection, not very applicable
Rust: Too complex, more like C++ but better. Bit too cumbersome to write "unsafe" code
D: More like Java/C++, although they have a "better C" mode, but feels like an afterthought
Nim: Uses garbage collection.. like D they're kind of trying to reach down into the plain C usecase, now with some nice reference counting stuff. Also relatively complex
Some actual attemps that I know of: C2, Odin
Some reasons why Zig is a better attempt at "C but better":
- Complexity of the language is just a little higher than C, and mostly in ways that resolves issues with C that leads to its own complexities (Like, the C pre-processor is simple, but solving problems with it can be surpringly complex. Or how you may have to resort to compiler extensions/pragmas to solve real problems)
- The Zig compiler is also a fantastic C compiler
- C headers can be imported and used directly in many cases
- Significant parts of the language is dedicated to excellent interop with C (even has syntax for 0-terminated strings)
- Cross-compilation is a highly prioritized use-case (C is very popular in embedded programming, where cross-compilation is essential)
That said, I am super excited about the Zig project, and it hits a sweet spot for me in a way that none of the other "C but better" projects have. Calling it another "C but better" language wasn't an attempt to disparage the project, but to classify it.
Right, but that's a (slightly) different goal from being a C replacement. There are other systems languages besides C, and C is used beyond systems programming.
E.g., if somebody came along and said that C would be bloody perfect if it just had a garbage collector then that alternative language would be totally unsuitable as a replacement for C in many contexts, but for a ton of other scenarios it'd still be "C but better," and I don't know that it should be disqualified just because it isn't a full replacement.
* Things that would be in scope, but the Zig project is not yet capable of supporting. An example of this would be compiling stuff to GPUs, e.g. SPIR-V. Such things are planned but not implemented. https://github.com/ziglang/zig/issues/2683
* Things that will never be in scope. An example of this would be code obfuscation, which is a use case the Zig project does not recognize.
* Object formats that are drastically incompatible with the von Neumann architecture. It would be infeasible for Zig code to be compiled to such things. For example, attempting to compile to CSS (Cascading Style Sheets).
I think that's it. Anything else would be supported, provided there were enough people interested in providing maintenance for the respective parts of the codebase.
I've even plugged zig into another highly concurrent vm and gotten it to be a "good citizen": https://youtu.be/l848TOmI6LI (these constructs are running concurrently in test and CI so I know they are robust)
Mobile app dev?
PS: My daily work involves writing Java/Kotlin for Android, and just started learning Flutter for cross platform mobile app dev.
I mean, if one day Zig support those, that's definitely super awesome. Of course I'm aware that more menpower on that direction is needed :)
It's better to mention in which areas it really excels, where it beats the competition hands down.