File for divorce from LLVM

Andrew is super sharp so I imagine he and the team will get there now that it&#x27;s declared as a goal.<p>But man, it seems to me (uneducated on the challenges zig faces w&#x2F;LLVM) that this shifts the team&#x27;s capacity away from zig and towards things like binutils. When I read the headline I assumed that they were throwing out the compiler (IIRC they had mostly&#x2F;totally excised it already). But for a project like zig it just seems like there&#x27;s a lot to be gained from keeping it.<p>That said -- the prospect of rewriting a lot of the stuff that&#x27;s in the LLVM project now in zig instead of c++ - that&#x27;s pretty cool and ambitious. Just as ambitious as it was for Lattner to create LLVM, I suppose.<p>But code that&#x27;s accidentally quadratic - well, that&#x27;s bound to happen to zig too, if it&#x27;s as popular and useful as LLVM project is.

Two issues here. The first is code generation and the other is bootstrapping.<p>Ime, the optimizing passes of a compiler are easy and fun to write. You have to read research papers to understand how register allocation and ssa form works, but it&#x27;s fun code to write. You just send the ir through various optimizing passes, each refining it in some way. You can write high-quality optimization passes without llvm. But then you want to linearize your ir into machine code. This step is boring and mundane to write unless you care about all the different ways x86-32&#x2F;64 can encode a &quot;mov [eax+8*ebx], 123&quot; instruction. If you are optimizing for binary size, do you want to bother measuring on which platforms &quot;push eax; push eax; push eax&quot; is shorter than &quot;add rsp,12&quot;? And this is just for x86. Multiply it tenfold for all the other non-x86 architectures irrelevant to most developers. The chance of having major bugs in the code generator for obscure architectures that stay undetected for years is very high.<p>The second issue is bootstrapping. What compiles the Zig compiler written in Zig? You could, for example, have a non-optimizing minimal Zig compiler written in C that compiles the Zig compiler. But since it&#x27;s non-optimizing, the Zig compiler would need to be recompiled with the optimizing Zig compiler. Not unsolvable problems, but ime long and complicated build processes risk driving away potential contributors.

With the amount Zig promoted being able to use it to compile c (and maybe c++ I forget) only to decide no LLVM at all seems wild. Without a LOT more people chipping in to support the odds of even coming close to the platform support of LLVM seems incredibly unlikely as well. I would understand planning to add another backend of their own for those who want that, but just getting rid of LLVM seems... rash?

While on one hand, I admire the fastidious desire to reduce dependencies, the trade offs seem pretty dire.<p>The loss of C++ compatibility effectively removes the biggest thing that my Zig fan friends mention to me.<p>The loss of performance (however temporary they say) is the other piece they mention.

So I spent ~4 years writing all my embedded projects (and libraries) in Zig and now several &quot;tier 1&quot; supported arches are just going to be dropped?<p>It&#x27;s your language so do whatever you want but please adjust the branding accordingly...

The DLang has 3 compilers:<p>1. gdc - based on the Gnu compiler collection back end<p>2. ldc - based on the LLVM back end<p>3. dmd - based on the x86 code generator that I wrote for Zortech&#x2F;Symantec&#x2F;Digital Mars<p>They each have their pluses, minuses, and targets. But the D language each supports is the same.<p>Overall, our users like the choice. Some even use more than one.

One of the main reasons Zig was interesting to me was the fact that I could drop it in as an alternative to a C&#x2F;C++ compiler. On Windows, my friends have mentioned how it is easier to install Zig as a C&#x2F;C++ compiler than any other alternative.<p>If this proposal is accepted, I personally think Zig will drop to the popularity level of Hare or other extremely niche languages. Getting my colleagues to even try Zig out required me sending them articles about how Uber was using it in production. There is no way my colleagues would even have given it a second thought if it didn&#x27;t have immediate value to their existing projects.<p>But I get where the proposal is coming from. LLVM compile times can seem awful, and there&#x27;s lots of neat optimization tricks you could implement with your own byte code. And dealing with bugs in LLVM is basically a no-go, I&#x27;ve seen this happen in the Julia ecosystem as well.<p>If my recommendations are worth anything, I think Zig should<p>1. Use a custom bytecode for debug builds - fast build times, fast debug times etc 2. Use LLVM for release builds - fast runtime performance, slow release performance<p>If they can manage 1.) while still maintaining support for cross compiling C&#x2F;C++ (just pass that part off to LLVM?) I think that might be the best of all worlds, with the tradeoff that there&#x27;s additional backend code to maintain.

Approaching this from the lens of an interested observer with experience with other projects working on non-LLVM backends for their languages, I&#x27;m just struck by the amount of hubris in the linked proposal.<p>If it weren&#x27;t for the author, I&#x27;d have dismissed the whole thing as a low-effort GitHub issue by a Zig newbie. The underestimation of the work involved, the backhanded dismissal of all the work that has gone into LLVM, the &quot;obviously we can do it cheaper, faster, better&quot; confidence&#x2F;machoism that exudes from each sentence or claim.. I&#x27;m disappointed.<p>I&#x27;ve had nothing but respect for Andrew&#x27;s work in the past so I&#x27;m going to extend him some grace and the benefit of the doubt and say that maybe it was just written in haste or on a whim without paying attention to how it came across. But it&#x27;s not something that inspires me with confidence or lends me to give the proposal itself more of a chance.

The correct time to build something without LLVM was years ago, but taking the C++ functionality out now will probably be the end of Zig. I&#x27;m surprised they didn&#x27;t announce a plan to write their own C++ compiler in Zig instead of phasing it out.

Zig wants to be the world new <i>C</i> not so much the worlds new <i>C++</i>. You’ll note that <i>C</i> cross compilation would still be supported under this proposal.<p>I think this might be the right choice. C is currently used heavily in the embedded world, and that’s a space where llvm is not good. If I was Zig, I’d want to be able to target all the microcontrollers and this is the only real way to achieve that.

One of the its biggest features is that the Zig toolchain is vastly superior to any other and opens up new possibilities to Devs of C&#x2F;C++&#x2F;Obj-C. One of its biggest selling points is to be able to use build.zig inside of projects with a C&#x2F;C++&#x2F;Obj-C codebase and thus get around using a shit ton of build tools.<p>If zig cc and zig c++ die I would instantly stop using the language!

Some of this reasoning is just wild.<p>1. &quot;We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs.&quot;<p>They are nowhere near popular enough (or used enough by some particularly important customer) for any major architecture vendor to spend any time contributing except as someone&#x27;s random side project. To think otherwise is ... really out there.<p>2. &quot;We can implement our own optimization passes that push the state of the art of computing forward.&quot;<p>There are in fact, no magic bullets. Once you pass the baseline of optimization capability, the reason these compilers do well is because they&#x27;ve been worked on forever, and made better 0.2% at a time.<p>Also, anything you implement they can implement. Maybe it takes annotations, or whatever, but that&#x27;s about speed and not capability.<p>3. &quot;Compilation speed is increased by orders of magnitude.&quot;<p>Uh, not if you are doing #2. Most optimization passes, especially when you are first productionizing research, are quite bad. It takes a tremendous amount of applied engineering to make them fast.<p>This is what i did on both GCC and LLVM. Implement and speed up ad nauseum. I implemented plenty of high-optimization-value, never been productionized before algorithms. It usually took a few versions and lots of slow-compiler bugs to figure out the best way to implement. It turns out most researchers are not spending their time working on the compilation speed. At best, they care that it&#x27;s passable.<p>For existing well-productionized algorithms (which don&#x27;t push the state of the art), you will not get orders of magnitude speedup. You may get some percent depending on how you structure your compiler.<p>There are certainly slow parts of LLVM, but it&#x27;s hubris to believe you are going to make something both better optimizing, and seriously faster, for this kind of language. There are other languages for which it is true. Zig is super unlikely to to be one of them.<p>The way you gain compilation speed for this kind of language is to optimize less. Spend as little time processing things into machine code as possible, using as fast of algorithms as possible, and where you can&#x27;t, relying on heuristics and such more to help generate good enough code most of the time.<p>There is more, but man, this feels out there.<p>If they said &quot;we want to get 90% of the performance at 60% of the cost&quot;, sure, maybe. But saying, basically, we will get &gt;100% of the performance at &quot;orders of magnitude&quot; (their claim) less cost is just, as i said, a wild idea. I wish them the best of luck.<p>Everyone who tries to reinvent good infrastructure is doomed to discover why that infrastructure was invented in the first place .

Surprising that the issue is full of comments from users who are currently using Zig to compile C++. Hopefully this won&#x27;t be the deciding thing.

This move... is it for great justice?

I&#x27;ll admit that I&#x27;ve only considered using Zig for its ability to easily compile (and cross-compile) C&#x2F;C++ code into static binaries.<p>Hopefully if any of that functionality gets removed someone manages to fork off the &quot;C&#x2F;C++ magic&quot; part into its own project. Clang itself is much less convenient to use.

I misread the title and expected to see a LLM that was designed for the specific use case of filing for divorce.

Every time I hear about LLVM, it turns into a rant. Clearly there is a problem there that needs to be fixed. Maybe the LLVM project team should address those issues.

Andrew even thinking about dropping LLVM, says all I need to know. Its going to become the next D language of 2020s. LLVM has decades of mistakes FIXED, and rewriting the first time, even the 6th time is always... filled with huge mistakes and security issues...HUGE.<p>brew uninstall zig. Thats what I did when I read it. I do not want to waste any of my time on soon to be dustbin tech.

Since they only mention dropping support for C++, Objective-C, and Objective-C++, I assume this means C is still supported?

Does anyone have any good examples of Zig being used as a build system for a large project?<p>Coming from a Windows world when my gigantic C++ project is hidden inside a vcxproj I dont delve into that often, I tried to compile a standard autoconf based project into wasm the other week and eventually gave up.<p>Use autoconf to create your cmake to create your make which builds your lib? and wrap all those calls with emscripten calls...or something along those lines. It was exhausting. Eventually it errored out becuase it couldn&#x27;t decide if the size of a size_t was available. I was tempted to just remove that line from the cmake.

Another angle on this:<p>As it is know, Uber - and some other heavily-capitalized firms (BigTech or otherwise) - use Zig (at least) for &quot;straightforward&quot; C++ compilation.<p>- What about asking your managers to seriously fund the Zig project?<p>It&#x27;s only fair from all the value you&#x27;re getting from it. And, then, reinventing an important part of the huge wheel that&#x27;s LLVM wouldn&#x27;t be such a seemingly unfeasible tall order.

My feeling is that if Zig drops C++ support, there seems to be enough momentum on the C++-dependent users, that they will just fork Zig...<p>Can&#x27;t LLVM be optional, and have unit tests guarantee that it works as before?<p>The above, or - as mentioned elsewhere, implement a C++ compiler in Zig: quickly, and before making any breaking changes - quite a tall order.<p>Or bring into Zig an existing pure-C, C++ compiler.<p>...TinyC&#x2F;libtcc? PCC? LCC? (wild guesses)

I think they should keep LLVM as a fallback or as an optimizing backend.<p>This part is pretty solid, even if all the dependencies is hard to deal with, I am not convinced that building your own would lead to better results.<p>The most annoying part is the slow compilation in non-release, this can be fixed more easily with support for a minimal number of targets.

There&#x27;s a typo in the article: it should be &quot;all our bug are belong to us&quot; (rather than &quot;all our bugs&quot;)

Did they consider MLIR ? If not, Did they mention why?

Really commend the ambitious move here. If successful it would be such a differentiator blazing a new trail!

Hands up if you initially parsed this as using a LLM to file for divorce?

Oh no, Zig is going down the Elm path

Given the barrage of negative comments on the PR and here as well, it really feels like Andrew is the only person in favor of that change.<p>It&#x27;s his language, obviously, but I strongly suspect that if this PR goes through, it will completely kill any kind of momentum that Zig has today and will most likely doom the language to obscurity.<p>Which would be a real shame.