Zig’s compile-time execution capabilities can surpass Rust entirely in terms of safety.
Leveraging more powerful compile-time computation, provide foundational abstractions and primitives for building custom tools: allowing developers to define their own abstractions directly and implement business logic on top of them.
The core purpose of all the above design and implementation is one thing only: to let developers maintain full control over the entire engineering code they design and write.
zig isn’t abandoning LLVM, just making not required for major architectures. It will, for the foreseeable future, support using LLVM as a backend.
Even if/when the ambition of competing with llvm as an optimising backend is achieved, they will likely still support using it.
The main, current, motivation for the custom backend is compilation speed in debug builds, but also release builds when they get that far.
What does this even mean? Do you think LLVM is the only way to make a low level language?
The compiler already separates the front and backend, its what allows it to have llvm and its custom backends. As I said earlier, zig will likely always support LLVM and by extension support multiple backends.
That wouldn’t be possible without separation of the two layers.
I get the impression you just think the zig team is incompetent?
This has nothing to do with the custom backend, or backends in general at all.
Forgive me if I sound hostile, but I’m just confused to what the point of this post is.
I get the impression this is translated, whatever tool was used doesnt seem to have gotten the intent across.
Building their own compiler backend means the team has to handle compiler adaptation for various chips on their own. I don’t think this workload is manageable by a single team.
I’ve always believed that the implementation of language features should be completely independent of the compiler backend. Any language feature can be implemented without touching the compiler backend at all.
well it’s a good thing they are getting more and more donations so they can hire more people. Not to mention all the people to contribute for free in their own time. If you think they are or will be struggling, why not help them, via a donation or contributing?
Okay… but zig is not implementing a custom backend for any language features.
By that logic I think you should support this, since one of the reasons is that LLVM is hard to work with since it primarily designed for c/cpp.
Zig is not abandoning LLVM. The core team just wants to make it possible to have debug builds on major platforms not depend on LLVM. That significantly simplifies development, and allows for more tricks like incremental compilation.
I worry that this approach will eventually lead to fragmentation: diving headlong into building a custom, self-contained backend with no dependencies on LLVM whatsoever, which would completely isolate the entire ecosystem.
I don’t think that’s going to happen. I honestly don’t think anyone wants to do an optimizing backend at LLVM scale. People want better development experience. Even as a user, I benefit from the faster debug builds, but I wouldn’t be using Zig if it didn’t have LLVM backend for release builds.
Divide what ecosystem?? There is no ecosystem of zig compilers.
If you’re talking about backends in general, it is already divided, there are LLVM and GCC as the big ones, and plenty of smaller backends e.g. QBE or tilde etc.
I think your fear is unfounded, you said that we should have an end to end thinking, then try to have an end to end thinking too, why would a team remove itself from LLVM ? What benefits would it bring ? None. They will never abandon the LLVM backend, because there is no reason to do so. What they are trying to do, is create a platform where if needed you can contribute and implement your backend for your target, where all the language doesn’t depend on LLVM being here. If anything that’s super smart, because the time it would take for you to understand LLVM, implement a backend for your target, and on top of that upstream it, is probably a multi year project.
And from a developer perspective what do you prefer ? Obscure mailing list, compile time for each compiler that can take upward of 2h per compilation cycle each time you do something ?
Or would it be nicer to have a compiler capable of compiling everything in less than 10s ?
From a developer perspective, do you think it make sense to have to read some of the most horrid C/C++ code out there into a mess of millions of loc littered with #ifdef#define#elif directives ? Or is it better to have a simpler codebase where you can pretty much just plug your backend into an enum somewhere and start working on it ?
When people ask why I do so much Zig instead of more popular languages like Rust, is because I really believe that an ambitious project like Zig is needed, even Chris Lattner who created LLVM realized that it was not optimal and decided to create MLIR instead of extending LLVM IR for his usecase.
So yeah, Zig should absolutely make their own backend, their own linker, their own build system, their own optimization etc. I think that when the language stabilize and gets more known, that a lot of people, are going to be able to ship a debug backend for Zig faster than their colleagues for C.
I most certainly want an optimizing backend in Zig that competes with LLVM, because LLVM’s optimizer pipeline is something people fight with on a regular basis. Examples include dead code not being removed in asserts (Ghostty has seen performance issues with this), and important optimizations kicking in only if you, through black magic and luck, get the right CFG shape (example: labeled-switch based dispatch loops randomly gets faster or slower than while/tailcall-based dispatch, depending on prong count/size/etc. And then there’s the issue of the LLVM optimizer pipeline being stupendously slow, making benchmark iterations (which I’m doing right now) a painful experience.
I think this is the core of the misunderstanding. AFAIK LLVM won’t be abandondend for the foreseeable future, Zig just doesn’t link against LLVM anymore because this close entanglement of the Zig and LLVM codebase turned out troublesome (understandable if you ever had to compile LLVM yourself, or deal with migrating from one major LLVM version to another).
Instead Zig just switches to LLVM-IR as the new interface to LLVM (instead of the LLVM library API), e.g. Zig gets its own LLVM backend generating LLVM-IR, which is then fed into separate LLVM cmdline tools to apply optimization passes and generate the actual native code (that’s at least how I understand it from the outside).
E.g. the whole ‘LLVM divorce’ thing is more or less just a technicality how Zig talks to LLVM in the future.
A lot of this thread comes from a big misunderstanding. Zig isn’t abandoning anyone. Zig is doing nothing more than un-bundling LLVM and freeing itself from a gigantic dependency.
LLVM becomes an optional backend in a separate package, which means you pay the cost of the download and disk space only if you choose to use it (such as for your embedded or otherwise exotic target). There are many targets that LLVM doesn’t support or doesn’t support well. In these cases, you use the C backend, which will also always be supported because all these use cases are important.
LLVM having competition would be a very good thing. It forces them to get better.
The most interesting part about having an alternative to LLVM is that it speeds up the development of Zig itself.
There was a presentation Andrew gave at one point where he shows how many issues there were in the compiler, and explains that the only realistic way to take care of them is to invest in making it faster to re-compile the compiler.
I feel like it’s similar to the old quote about “if I had x hours to chop down a tree, I would spend x - 1 hours sharpening my axe.”
This trick alone is worth a million bucks and goes an awful long way in justifying the effort to ADD the custom backend, to provide an alternative to LLVM for major architectures.
And, perhaps more to the point of this thread, once we start invoking external clang/llc, it’ll actually be possible to target LLVM forks for targets which haven’t been upstreamed yet. You can’t currently do that because such forks are almost never tracking the latest version of libLLVM.so which Zig generally requires.
So the end result is more target support, not less.
Even for the end user, compile time with C++ are painfully slow,. I’ve literally spent the last few months rewriting an embedded project at work bit by bit to remove dependency on libcamera, opencv to finally get rid of C++/python and have only C code, now i get a full build under 20s (which is still insanely long) going from the base build which used to take more time than it takes to build llvm and would require adding 4gb of swap to the pi to prevent it from OOM I’ll take that as a win.
I’ve now started replacing the cmake with build.zig, and so far it’s much faster, when I’m done rewriting it, if the aarch64 backend and incremental make good progress, I’ll literally be able to have one terminal with zig build watch -fincremental and get ms compile time, that’s a game changer, when I was given this project it was literally 1980 compile time, now it’s bearable, albeit 20s for a project under 50k loc is still mental when the full zig compiler can be rebuilt for small changes in 10s and it’s maybe 10/15x the size.
So yeah definitely a huge win for everyone to build custom backends, and linkers, and definitely one of the biggest selling point of the language if you ask me.
In the embedded space, the best supported alternate architecture is ARM and that is generally gcc via ARM rather than clang/LLVM. I believe the clang version requires a special license (paid?) from ARM. I don’t think anybody else is on clang/LLVM (maybe RISC-V?) So, abandoning clang/LLVM is kind of a no-op.
Supporting “every” chip architecture means supporting: x86, ARM Cortex-A, ARM Cortex-M, and RISC-V. That’s not a lot.
Hello welcome to Ziggit! I see this is your first time posting. As others have pointed out it maybe better to seek understanding from the community and the core contributors about the direction of Zig before advocating for things that it seems you do not have the full context of. I hope that you stick around, I think I can speak for most here and say you won’t find a more helpful community when it comes to zig. Everyone is very passionate about zig and only has it’s best interest in mind, and I think that you should come here to help better understand the design decisions (with full understanding of context), and contribute to the conversation in a calm and reasonable way.