There is space to enjoy writing code with someone’s PhD dissertation, untyped dynamic free for alls, and all that in between. Zig feels like a hacker's language.
I'm interested in learning a lower level language a bit better. I've spent some time in Rust and C (not enough to be proficient) -- is Zig a good candidate? It seems to have a lot of interest, I'm curious about objective views on its long term progress and forecast.
Before Rust and Zig, I thought I disliked systems programming, while as it turned out, I mostly just disliked C.
However, when it comes to actively maintaining a serious project you do need to take extra care, since using a pre-v1 language does require a lot more efforts, since even in a post-v1 language you need to handle lib updates and such...
Also, even though I believe I'm no longer afraid of manual memory management, explicit allocators, etc. for writing regular userland applications, I still think Zig can be too low-level for certain problem domains from time to time (the same thing for C, and I believe Zig is there specifically to target C programmers), so it's really about finding out which tools would be a great fit for you in which scenarios.
I learned that I was wrong when I spent some time hacking around lower level programming with Zig and I thoroughly enjoyed it. It just clicks for me in ways that C and C++ never did.
Luckily around the same time I also got hold of Turbo C++ 1.0, and Borland's Pascal / C++ tag team is what kept me interested.
Operating overloading is considered hidden control flow. I appreciate that the team set made and are adhering to principles, but it does not mitigate the downside of this omission to me. I do a lot of scientific and numerical computing, and use vectors frequently. Non-overloaded vector syntax is tough to read and write.
I'm aborting. This is an unfortunate decision.
LOL. At least that is 20 min of trying. ( From the first message to above )
- Embedded (Accelerations, velocities, positions)
- Robotics
- Games
- Performance-critical scientific and numerical code (Cosmology, computational chemistry etc)
- 3D graphics and visualizationsHe has other choices after all. If this represents a negative that out-weighs the positives, so be it.
These same design decisions in Zig may make it a top tier option for other tasks. Just not this one.
happy to be told I am an idiot, and don't get it, but only with good reasons :)
( as a guy who did quite a lot of C earlier, including in prod, I was interested in the goals of zig, but it should work for my needs, in the sense that I describe above. )
and I will decide what is good for me :)
now, zig away!
In particular:
- LLVM is not enough, let's write our own compiler.
- Interfaces are an overhead, use comptime instead or roll your own vtables.
- In a world where "memory unsafe" languages are under attack... yeah, we don't care about that.
I'm not trolling, this are serious questions from afar that I would love to figure out before investing time with Zig.
[Edit: expanding]
For instance, completely platform-independent cross compilation is something Go popularized, but Zig really nailed. (In fact, if you use cgo, the generally accepted method for Go cross-compilation is to use Zig as the C compiler!)
Another interesting thing about Zig is that it happily compiles C code, but brings more modern package management. Loris Cro has described how it would be quite reasonable (and pleasant) to maintain C code using Zig: https://kristoff.it/blog/maintain-it-with-zig/
May be more accurate should be they believe compiling should be insanely fast. And incremental compilation is part of the tools to achieve that.
- Fast build times (closely related to IC, but LLVM gives very slow development iterations, even for the compiler development)
- Language innovations: besides IC, async/await is a feature Andrew determined to not be feasable to implement with LLVM's coroutines. Async will likely not make it into 1.0, as noted in the 0.13 release notes. It is not discarted yet but neither is it the priority.
- There are architectures that don't work very well on LLVM: SPARC and RISC-V are the ones I remember
My personal point is that a language that is meant to compete with C cannot have a hard dependency on a C++ project. That, and that it's appealing to have an alternative to LLVM whenever you want to do some JIT but don't want to bring a heavy dependency
[1] https://www.youtube.com/watch?v=5eL_LcxwwHg
* There is also the `--watch` flag for `zig build` which re-runs every step (IC helps) everytime a file is saved.
[edit: formatting]*
Also if they value compilation speed that much, maybe they shouldn't be that pushy into compiling always from source, without any support for Zig binary libraries.
Nope. Different languages have different priorities and different USPs. For Zig sub-second compilation / incremental compilation, cross compiling toolchain are flagship features. Without those there is no point in releasing 1.0.
FWIW Zig does offer spatial memory safety, but does not provide temporal memory safety in the language (e.g. "dangling references"). It also fixes most of the 'sloppyness', UB and general footguns in C and C++ (and most memory corruption issues are a side effect of those).
Temporal memory safety can for instance be achieved via generation-counted handles (e.g. see: https://floooh.github.io/2018/06/17/handles-vs-pointers.html and https://github.com/zig-gamedev/zpool/)
It is overall better, IMHO, and the ecosystem and safety pay dividends.
But Zig has several nice things (I don't use it directly but appreciate them, and is my way to cross-compile to musl):
* Is truly faster to compile
* Is far better to cross-compile
* Is far smaller
* comptime is a much better `macro` language. I don't like the ergonomics of the split on Rust between the 2 styles of macros, where proc-macros is a cliff of complications
I think Zig fits the bill for `C is a compiler target`. Whatever I need to integrate with C or generate C I think it is now better to target Zig.
That is for speed during debug builds. For production builds zig will still rely on LLVM
I would love to try it out with a serious project, but am waiting on libs like HALs for microcontrollers, GPU API bindings, GUIs etc to mature to a usable point.
https://github.com/floooh/chipz-kitty
That's one nice thing about Zig, such small experiments are quick to setup and fun to build.