Does anyone know if zigs reached the point of maturity to having solved most compiler bugs? I used it a couple years ago and it failed HORRIBLY for anything real I was throwing at it.
I’ve been using zig for hobby projects for the last few months and have yet to run into a compiler bug. Tracking down comptime errors can be a little bit confusing, but I’ve found the compiler to be stable and useable.
The switch to the Zig implementation fixed a ton of bugs, but introduced way more new ones. I've used it in anger for almost a year and simply gave up at some point and switched to Rust because of the buggy build-ins and broken compiler error messages.
Tbh I doubt that this situation will improve now that they bit off even more from the compiler cake after having more than they can chew already.
Isn't the idea that bootstrapping the compiler let's people who only know zig contribute to the compiler? Might it be too premature to declare failure?
In theory maybe, but after watching Andrew Kelleys latest talks I don't get the feeling that the Zig implementation is build for readability and correctness, but an experiment for exploring the design space of data-driven-design in compilers.
We switched to a self-hosted implementation of the compiler since then. The old compiler had various age-related issues, Cpp-related issues and it made little sense to fix it since the plan was to replace it anyway.
The new compiler is a much better codebase and compiler bugs get fixed much more quickly and effectively.
Maturity to fix most compiler bugs? Yes, on x86_64 (some bugs remain on other architectures). But you can still expect your code to break between zig versions.
to anyone considering Zig, note that its coming along pretty nicely, but still has some big missing parts. for example currently only TLS 1.3 is implemented, which means that HTTPS requests are going to fail with many servers:
It's a bit more nuanced than that, as detailed by AndyKelley (andrewrk@) on github[1].
As I understand it, C/C++ interop and support in the build system is not going away; instead it might be accomplished via a separately maintained clang package. (Aside: for an example of this kind of thing can work, see ffmpeg[2] converted to use the Zig build system which pulls in nasm[3] as a Zig package; presumably the clang solution would be a bit more integrated than that, but it serves to show that it can be done).
Zig will still support compilation using LLVM, but instead of directly linking to LLVM and using LLVM's IRBuilder API, it will directly output LLVM bitcode instead[4]. The build system will then handle linking this into an executable, possibly by calling out to the LLVM linker.
The idea seems to be to reduce dependencies of the main executable, while keeping the build system flexible enough that it does not impact existing use cases.
I'm not affiliated with the Zig project in any way, so my understanding of this may be off. I'd recommend reading the GH issues and comments I've linked below to get a better idea of it.
- the Zig compiler will get a new integrated C frontend written in Zig
- ...and a new backend which can emit LLVM bitcode (so it's still possible to integrate with an external LLVM toolchain)
- C++ and ObjC compilation (or Clang's specific flavour of C) will be delegated to a package dependency which includes a clang toolchain, accessible through the build system
...so things will be shuffled around, but no functionality will be lost.
They want to remove the dependency on LLVM, but also they plan to keep shipping clang as well, I believe. Probably they will ship 2 different zig binaries, one that is only able to compile zig and c, but without the help of clang, and one that includes clang as well, and can compile c++.
This talk on YouTube seems to suggest that not everything is all hunky dory with Zig as a C/C++ compiler (with reference to libc) but I cannot remember any details since it has been almost a year since the talk was published.
I wonder if things have changed? Does anyone know?
No this talk is about something entirely different, the idea of giving a libc interface to Zig's standard library in order to use it whenever a C project needs a libc dependency and wants static linking. Currently Zig uses musl for that but in a future it could just use its own stdlib instead.
As an addendum, using zig to build libc is going to be amazing. It'd be like a compile-time ld_preload -- so less magical and you have much more control over the scope
I wonder if it's worth it to use zigs build system in projects. I've seen tried and failed to build a number of zigs projects when I'd last looked into it.
Curious which projects you had issues with? I've only had positive experiences using zig build. Maybe you ran into version issues because 0.11 changed the entire build api?
Especially the build system had tons of changes on the way to 0.11.0, and many Zig projects seem to prefer to "live on dev", so frequent breakage wasn't all that surprising during the last year or so.
The language is in flux at the moment, so unless the projects are updated to use master (and are being built with master), one tends to run into incompatibilities not infrequently.
