make the main zig executable no longer depend on LLVM, LLD, and Clang libraries

Question

make the main zig executable no longer depend on LLVM, LLD, and Clang libraries

andrewrk opened this issue a year ago · 202 comments

Answer 1 · 2023-06-29T23:06:39.000Z

I see the 1.0.0 milestone for this, is it meant to be a blocker for 1.0? or simply the goal

Answer 2 · 2023-06-29T23:08:23.000Z

The milestone, on an issue labeled "proposal", means that a decision must be made to accept or reject that proposal before tagging the release corresponding to that milestone.

For an issue labeled "accepted", the milestone means that it must be implemented by then. So, if this proposal is accepted, then I will evaluate at that time which milestone to move it to.

Answer 3 · 2023-06-29T23:26:17.000Z

In the near term, the machine code generated by Zig will become less competitive. Long-term, it may catch up or even surpass LLVM and GCC.

IMO, this is the biggest question. One of the most compelling reasons to use Zig is runtime performance of software written in Zig. Without LLVM's optimization passes, what will that look like?

Answer 4 · 2023-06-29T23:40:21.000Z

Long-term, it may catch up or even surpass LLVM and GCC.

We can implement our own optimization passes that push the state of the art of computing forward.
We can attract research projects such as alive2
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.

Zig will continue to implement optimization passes of its own over time and get faster.

Answer 5 · 2023-06-30T00:01:07.000Z

So here the projects that depend on the ability to compile C++ that I currently developing:

https://github.com/Cold-Bytes-Games/wwise-zig: I am using the C++ ability to compile glue code to create a C binding. I plan to use this for audio in my game BioMech Catalyst written in Zig.
https://github.com/Cold-Bytes-Games/wwise-zig-demo: Using previous mentioned library plus zgui that does a nice Zig binding on top of Dear IMGUI
Still planning to use zgui for my game editor in the future.

And also some NDA game platform that have C++ only API that will require some C++-to-C glue code to be compiled, but obviously not implemented.

To me, the ability to seamlessly build any C, C++ and Obj-C is a big selling point of the Zig toolchain even if it is behind a optional flag to enable LLVM and Clang when compiling Zig. A part of the hype momentum around Zig is due to that fact.

If this happens, I think I will remove my donation to the Zig Software Foundation.

TL;DR: Lots of libraries in the game development world (closed or open source) require the ability to compile C++.

Answer 6 · 2023-06-30T00:05:09.000Z

I think this proposal would hurt the Zig ecosystem more than it would help it, due to several reasons:

Adoption of compilers and languages in the embedded is basically driven by the code generation quality in terms of size. We have to be on-par or better than GCC and LLVM to be even considered tmto be adopted. 2%-5% bigger code is often not an annoyance, but a technical problem.
A lot of projects use C++ code and might benefit from build.zig "as is". This could lead to adoption of Zig, with the build system as a kick-start. Removing support for C++ will hurt adoption a lot, because now the build of C++ projects with some additional Zig code will be even worse than just adding more cmake. Thus, a lot of projects wouldnt benefit from Zig in terms of quality of life, as it is yet another build tool.
Zig is with its "batteries included" cross-compilation the best toolchain for doing native development. We would basically downgrade our toolchain to something Go where we rely on external tools to successfully build more complex projects. Even in the current state, its often so much easier to yeet zig at something to get it to build than even trying to get a cross-build running with existing tools
Considering the scenario i have at work, introducing Zig as a build environment for several million lines of C++ would make a lot of people happy, as the builds would be faster, easier maintainable and trivially portable to other OS. With C++ and LLVM support removed, i dont see any chance of Zig adoption at this company

Imho, this proposal strongly violates the

Together we serve end users

idea, as the current direction we're heading is a really good unified native build environment based on a single static executable that can serve projects in arbitrar, sizes, shipping compilers for several major languages, a huge ass support for targets and a build system, making work in systems programming fun, even if one doesnt use Zig as a language.

We are on a good way to replace a huge list of tools with a single executable, making contributions to projects build on Zig fun, easy and platform independent.

When this proposal is accepted, in addition to Zig one will need to have the following tools installed:

(GNU) Make
premake
meson
CMake
ninja
$(arch)-$(os)-$(abi)-gcc
llvm/clang
GNU autotools
m4
vcpkg
gradle
conan
qmake
SCons
maven
...

We can potentially replace all of those tools wit a single, equally powerful executable, making the live easier for all native devs out there

personal projects that would be affected:

https://github.com/MasterQ32/cg-workbench (fully written in C++)
https://github.com/MasterQ32/zero-graphics (Scintilla is written in C++)
https://github.com/MasterQ32/zig-assimp (Assimp is the de-facto standard solution for generic 3D model loading, written in C++)

Answer 7 · 2023-06-30T00:20:04.000Z

I'm still a beginner I believe, but if it is at all worth it for me to give my point of view, Zig's ability to replace all of the build tools mentioned above is a big reason I was interested in Zig in the first place. I struggled a lot with all the different build systems and Zig is a really refreshing breath of fresh air.

I have two personal projects that use zgui heavily and I had planned on continuing.

Answer 8 · 2023-06-30T00:27:47.000Z

With Mach engine we have two dependencies that would be very, very painful to remove (would set us back years):

DirectXShaderCompiler (DXC) - a Microsoft fork of LLVM 3.7, which generates DXIR (LLVM IR) which is what direct3d graphics drivers consume. Microsoft is trying to upstream support for emitting DXIR (specifically LLVM v3.7 IR) to the latest LLVM/clang version.
Calling into Apple's Metal shader compiler - which converts Metal's text shading language into (yet another fork) LLVM IR bytecode, which is what the Metal API consumes - only this one is proprietary and undocumented. Obj-C is the only way to invoke it, I believe.

It will be a long time before Zig's SPIRV backend is capable enough to generate non-GPGPU shaders for graphics APIs (if ever, since it would likely require major language changes) - so I don't see a way for us to escape these aside from replicating what these two projects -- LLVM forks -- do on our side.

Every other C++ dependency I believe we could safely escape from.

Answer 9 · 2023-06-30T00:34:24.000Z

A positive long-term effect of this change is that it would push us as a community away from wrapping C++ code and towards more pure-Zig solutions.

Many of the comments in this thread are about people using zgui, wwise, zig-gamedev, assimp, and other C++ libraries wrapped with Zig. It gives you a leg up in the short term, but I worry in the long-term that people's gamedev experiences coming to Zig will be 'initially I saw a nice language... then I encountered the guts of the libraries I was told to use were large, clunky C++ codebases'

Answer 10 · 2023-06-30T00:38:52.000Z

Also a beginner, but I think being able to use Zig as a C++ build system (which is what I use for all my private C++ projects) is an invaluable feature to me and I believe many other people. The simplicity of Zig, having a compiler and a build system contained within a single executable (with the added bonus of being easily cross platform), is really cool, and it would be kinda unfortunate to see that feature be removed as an effect of removing clang and friends. However, if this does go through, the ability to fallback to generating .bc files and invoking clang is nice.

Answer 11 · 2023-06-30T00:50:38.000Z

One of my friends pointed out that nothing stops you from invoking clang in a build.zig to compile C++ dependencies, even if Zig stops including clang. I wonder how much of a problem that would really be for these projects?

Answer 12 · 2023-06-30T00:54:00.000Z

doing that would be an additional dependency without the ease of zigs cross compilation

Answer 13 · 2023-06-30T01:35:28.000Z

Hmm, the more I think about this proposal the less I like it. I'm feeling it would be better to make the LLVM backend non-default (that is, switch -fno-LLVM for -fLLVM or something) but not remove it. It seems like this would solve most of the issues: the existence of many bugs that are LLVM's fault, and the slow compile speed, aren't strong reasons to remove the LLVM backend so much as make it non-default. It wouldn't solve the issues of the binary size of the zig compiler or difficulties with building it, of course.

Answer 14 · 2023-06-30T01:35:49.000Z

I think I can speak for all gamedevs by saying that removing C++ compilation would be a disaster. Too many amazing existing gamedev libraries and tools are built on C++ that disallowing easy use would strangle adoption in that field, as well as complicate existing projects. dear imgui is the obvious example but it's not the only one.

Answer 15 · 2023-06-30T01:39:02.000Z

It's easy to imagine that in the long term, this change will push us towards "rewrite it in zig" with all the benefits that would entail, but the downside is that the existing corpus becomes inaccessible; limiting our options heavily even once zigs ecosystem matures

Answer 16 · 2023-06-30T01:39:32.000Z

I think llvm is needed until ecosystem of pure-zig library is very very mature and rich.

Yeah we want faster compiling speed and smaller tarball, but not at the risk of losing one-zig-to-rule-all.

Answer 17 · 2023-06-30T01:56:06.000Z

I love the ambition of this proposal, but to reiterate what has already been stated, losing c++ compilation would be losing one of the main selling points of zig. I was drawn to zig in part because it reduces the hellishness of depending on c/c++ projects. Zig having a c++ compiler inside it also has the benefit of there being less c++ to have to deal with, less python to have to deal with, less cmake to have to deal with.

On the other hand, the core of this proposal has too many benefits for it to be rejected entirely. I think reducing the scope would be beneficial. How about:

Eliminate dependencies on LLVM & LLD
Keep clang as an optional dependency for easy cross-compilation

Answer 18 · 2023-06-30T01:56:27.000Z

I totally get the desire to get rid of huge third-party dependencies that bring a lot of baggage. There's also something to be said for avoiding an LLVM monoculture in the programming language space.

Even so, I see this as a net negative for users. What drew me to Zig in the first place was the pragmatic approach of acknowledging that there is a world outside of Zig that needs to be interoperated with for the foreseeable future and even providing a best-in-class cross-compilation experience along with that. I built my project integrating Zig build support with the .NET/MSBuild ecosystem on that selling point.

On the whole, I think this proposal would be an unfortunate (if well-intentioned) bait-and-switch, considering the Zig website for a while has advertised this:

In addition, these blog posts drove a lot of attention to Zig in the past:

Just to be super clear: I don't mean to insinuate bad faith or anything of the sort here. But I think it's fair to say that you have to contend with the fact that this proposal would pull features that are not only usable today, but are also prominently advertised.

All that said... assuming this is even remotely practical, maybe there's a potential middle ground: Would it be possible for Zig to continue to use the Clang frontend to provide C-family support, but rip out the LLVM IR lowering and replace it with lowering to ZIR/AIR? (I guess this is more or less how Aro would be integrated too?)

If this could be done, the codegen dependency on LLVM could be killed, achieving at least some of the goals of this proposal. There's probably also no reason to keep LLD support around as long as zld can catch up, so that eventually goes too. And users remain happy. Some of the build and distro woes would remain, of course, but, that's compromise.

Answer 19 · 2023-06-30T02:34:11.000Z

I’m fully in favor of making it possible to use Zig without any LLVM components, but I agree with many of the comments here that it’s important for Zig to maintain the capabilities that it currently has in terms of cross-compilation, compiling C/C++ code seamlessly, and generating maximally performant binaries.

These factors are big drivers of Zig’s adoption, and I fear that damaging them (even temporarily as in the case of code generation quality) would seriously hurt Zig’s future.

Personally, I work in the robotics space, where C++ is the dominant language for many libraries and frameworks. I think Zig has a lot of potential in this space, but being able to integrate with existing libraries is absolutely essential for adoption.

Answer 20 · 2023-06-30T02:41:31.000Z

(Please ignore my original comment. My use case is unchanged and I temporarily conflated two components.)

Is there a story in this proposal for JIT compilation? I have a Zig project with currently relies on LLVM's Orc to JIT-compile audio DSP functions. I'm not particularly stoked about or attached to Orc itself, but it does give me in-process compilation with low-milliseconds latency, something I'd need for dynamic real-time audio applications.

WebAssembly would not be an issue here because I wrote the Wasm compiler myself, but for x86_64 and friends I would need a replacement. Passing LLVM bitcode to a separate process might work but would feel like a downgrade. Vendoring and embedding the Zig compiler source might be the best option in that case.

(Aside: I have started work on reading and writing LLVM bitcode from Zig, and if this is accepted would be happy to resume work on that.)

Answer 21 · 2023-06-30T03:24:54.000Z

I'll start by stating my opinion: the C language frontends are super important to me for Zig to maintain.

I agree with others on the point that Zig being a C/C++ compiler is a big point of attraction that brought me to the language. I started with loving that idea, and ultimately fell in the love with the language, and now I use both. I don't have anything more to add to that that the others above haven't.

I'll add my own personal experience. I have many personal Zig projects, but my biggest one that people tend to know about in the community is my terminal emulator. There are two important dependencies that would be impacted by this:

Harfbuzz - The far and away single most complete cross platform text shaping engine. Text shaping for those that don't know is the process of laying out text, processing things like multi-codepoint emoji into single glyphs, Asian language handling, etc. This is not something you want to really maintain in your own language (i.e. write natively in Zig) because Harfbuzz is so good and so well supported. This is shipped as a single large C++ file with no other dependencies. Without access to Harfbuzz, gaming and manual-GUI applications (not using a mega framework) would surely suffer.
Objective-C for Mac work. Admittedly, this is probably deprecated over the long term since Apple is pushing very hard into Swift. Still, I use Zig's ability to compile Objective-C files to augment my native Zig Mac applications. I've personally written Zig objective-C bindings using the C API, but I also still like to just write some ObjC sometimes which would otherwise take a big mess of Zig/ObjC-runtime code. Again, I think I could find a way around this one, but I think its worth noting for now that ObjC is still a part of [low-level] macOS GUI development.

Andrew, your dislike of C++ is well known! I don't love it either (to put it kindly). If, as an audacious goal, you wanted Zig to lower C++ usage, I think Zig being able to compile existing projects and enable iterative migration away from C++ to Zig is the way to do it. I think if Zig doesn't support C++, the C++ "people" would just avoid Zig altogether.

Answer 22 · 2023-06-30T04:15:12.000Z

Main gripe seems to be the need/desire to be able to compile C++ due to the mountain of pre-existing libraries that are already being used in the Zig ecosystem. For this proposal to satisfy people and not to break a huge selling point for Zig, a C++ (and ObjC?) compiler in Zig would have to be up-streamed.

Dunno what madman will be the one to write that tho.

At the very least, any kind of serious effort towards removing LLVM should be done after reaching 1.0.

That said, I don't think divorcing from LLVM itself is a bad idea, if the Zig toolchain itself can slowly grow to replace its functionality, just so long as it sticks around until opting out of it doesn't result in Zig losing out on its existing features.

Answer 23 · 2023-06-30T04:36:09.000Z

While I can see this being a good thing in theory I like others have concerns over what it will do more short term. Zig to me is expected to be a highly performant language competitive with languages like C, if it is not performant then it impacts my ability to use it for writing the projects I am making in it because it simply will be a worse option in practice for such things.

Perhaps this could be mitigated if the C backend becomes fully functional to allow projects to compile to C code and have those compile with typical C compilers for when performance is needed, but otherwise I do not think this would be well-advised until some sort of reasonable performance guarantee can be made. Even with the Zig->C->Machine Code process I feel like you'd be losing some optimization potential as no longer would Zig be able to annotate LLVM IR directly and would instead be confined by whatever C can express language wise so that might not even be a foolproof option either (though at the very least it'd hopefully put it on the level of C for most things).

Edit: Apparently I've been told this is what the bitcode support could be used for, I've never used LLVM bitcode stuff myself before but yeah if that's a supported target and still gets focus knowing people will be using it to generate higher quality optimized code until Zig can compete maybe this is less of an issue, albeit a bit more convoluted in how a project would have to be compiled.

Frankly with how insanely complex x86 is and how much work has gone into LLVM over the years I am doubtful Zig would ever reach the same standard of performance. Other larger languages like Rust which aren't even as entangled with C++ haven't tackled this sort of challenge yet either for instance despite the some similar motivation to and more developer resources at their disposal, and to me that is not a very promising sign for its feasibility (though of course Zig could always be the first thing to prove this long-held mindset of LLVM being impossible to replace wrong...).

Also as an aside while I am not as invested in the C++ compilation support as others may be I do think that it'd hurt a lot of projects. Being a gamedev myself losing the ability to use ImGui would be unfortunate as others have mentioned, and personally I also use Tracy in some of my Zig projects which is also C++-based. It wouldn't be too hard to just compile these libraries and link to their binaries (or use a system library I suppose) but still that just makes Zig a bit more pain to interface with this stuff.

Answer 24 · 2023-06-30T04:46:49.000Z

Another thing that I don't think has been mentioned/considered yet, if this proposal were to go through, and that were to happen around or after the time that 1.0 is released, it could cause a split in the zig community.
Some people who rely on zig's current toolchain might choose to simply stick to an old version of zig so they aren't forced to migrate their codebase. This would harm everyone involved. Users and devs on the old version would miss out on any future features and optimizations, while the other ones, who chose to update, would be unable to use any of these libraries within their own projects without jumping through hoops to do so.

Answer 25 · 2023-06-30T05:20:56.000Z

I agree that apart from the mentioned problems with LLVM, it also struggles with the a baggage of legacy code, e.g. in TableGen modules, in how Clang is tied to LLVM compared to the newer compilers that use middle-level intermediate languages, how story of migration from FastISel and SelectionDAG to GlobalISel stalled for many years and isn't really progressing for all supported architectures, and so on and so forth. Using C++ language for writing such a complex piece of software doesn't help either. But even Rust didn't dare to get rid of it just yet. Thus, I think it would be prematurely to do that for Zig either. Long-term it might be a worthy goal, but definitely not in the upcoming 5 years or so, in my opinion. Just my 2c.

I second @yujiri8 here, having optional LLVM target for many years while working on the Zig backends would be a perfect strategy, reducing the maintenance of LLVM parts and providing room for experimentation and optimization of the mainstream targets directly in the Zig code: ARM64 and x86_64, probably RISC-V in the future, if it really takes off. GHC (Haskell) uses the similar approach for at least a decade already, it seems to work for them.

P.S. Why PE format is not in the list for linker?

Answer 26 · 2023-06-30T05:26:32.000Z

Maybe the best long-term solution would be to offer some kind of plugin system for the zig compiler.

Pros:

The compiler itself could take advantage of all the stuff listed by Andrew
Stuff that the community considers important, like compiling c++ could still be supported
You only "pay" for what you are actually using
We need some way to interact with different compilers/tool anyway to take full advantage of the c-backend, e.g. compiling zig code for some exotic platform that only has an compiler for c. This could be a more stable approach than just scripting with build.zig.
It would make it easier for people to add interoperability for even more languages than just c/c++ and experimenting with features in general
Could result in some federation. While a second implementation of zig compiler is a long time away, having a plugin system would allow different implementation of parts by the community, e.g. clang and arocc

Cons:

Duck tons of work
Even more stuff breaking when a new compiler version releases

Answer 27 · 2023-06-30T06:01:55.000Z

At least create a new external project to mantain the goodness of "zig cc c++ bpf..." and builtin platform SDKs .h and cross compilation!!

Answer 28 · 2023-06-30T06:41:23.000Z

There are a lot of people worried that loosing C++-support would be a problem.

I am curious how much of those problems would still remain if Aro (or something else) somehow over the year gained C++-parsing support. Would that help 50% of the worried people? 100%? 0%? There is a difference between parsing C++ and making libraries that are binary compatible with it so it might be harder that just parsing it so that is why I am curious!

An alternative idea here might be to try to remove LLVM/clang over time and also add C++-parsing support to Aro (or something else) such that when the switch actually happens, nothing goes away (or at least C++ doesn't go away).

Zig has ended up in a weird situation where on one hand it is a language but then maybe people like it because of how good it is at cross-compiling and mixing languages.

Answer 29 · 2023-06-30T07:05:42.000Z

With my limited insight into the project, the fundamental reason for removing LLVM integration doesn't quite make sense to me.
All the reasons for LLVM replacements listed here sound like good, valuable improvements that can be implemented without removing LLVM integration.
I see that LLVM is "annoying because it's large, slow, and has bugs" - but why remove the option to use it?

An alternative to full removal would be to make LLVM integration less of a priority:

Shift LLVM maintenance to dedicated team members / dedicated resource and time budget.
Reduce the scope of expectations - "LLVM is only tested/verified for these targets" and declare bug fixing for anything beyond out-of-scope.
- Maybe people would come together to set up their own independent funding around this.
  I'm sure there are enough well-intentioned people in the community that would be willing to maintain it while trying not to slow down core Zig.

Moreover, the current Zig compiler already has a fully modular structure.
LLVM is (as far as I understand it) already completely optional.
(The fully-self-hosted path isn't finished yet - but nothing seems to prevent it from working besides time left in the oven.)

Is the current structure not working or suboptimal in some regard?
Do we have some rough sketch of time investment with LLVM vs without to reach some goal post result X?
- Zig as a whole already looks so mature, and the integration already works so well for so many use cases, that it's a bit surprising to consider this part of the project (as opposed to self-hosted components) to require that much additional time investment going forward.

Answer 30 · 2023-06-30T07:17:45.000Z

Too many hours of work have been put into LLVM. The optimization passes, the IR and everything are really the best on the market right now and are constantly being improved. While I'm sure that zig's own passes could get to an incredibly good state, in the long term, improving LLVM instead is probably still what would provide optimal executable performance, and would also benefit the whole ecosystem.

If dropping LLVM dramatically improves compilation speed, then it could be used during development, for projects that don't require C++ or objective-C, in order to keep a fast development feedback cycle.

Answer 31 · 2023-06-30T07:44:03.000Z

Long-term, Zig plans to have Contributor-Friendly IR, or something equivalent, to optimize for low maintenance for supporting many targets that LLVM would never even dream of, for example MOS #6502.

I'm not sure that's a great argument given there's a fairly stable and performance-competitive port of LLVM to the MOS 6502, actually... It even supports Rust! While it is not upstream, it hopes to be upstreamed at some point in the distant future.

As a bystander, my opinion is: Removing dependency on LLVM, sure; removing any support for LLVM backends, I'm skeptical (though it appears that this may not be the case -> #13265 ). Even languages which have maintained their own backends for decades, like Free Pascal, are adding LLVM as a target.

Answer 32 · 2023-06-30T07:51:02.000Z

And here I was trying to figure a good way to also get zig lldb going so that a zig toolchain is a one-stop shop for developers.

I'm new to Zig, but the pragmatic acceptance of reality that lead to having 'zig cc' and 'zig c++' come to be is what convinced me to take Zig seriously and consider it as the foundation for a lot work. I'm now reconsidering and likely to put Zig back on the shelf.

But I look forward to seeing how things turn out! I'm pretty sure things will work themselves out for the better eventually.

Answer 33 · 2023-06-30T08:16:32.000Z

@slimsag

Many of the comments in this thread are about people using zgui, wwise, zig-gamedev, assimp, and other C++ libraries wrapped with Zig. It gives you a leg up in the short term, but I worry in the long-term that people's gamedev experiences coming to Zig will be 'initially I saw a nice language... then I encountered the guts of the libraries I was told to use were large, clunky C++ codebases'

Isn't it (mostly) the other way round? "Initially I set up my project with good C and C++ libraries, then I wrote my stuff in Zig, and having a polyglot project never caused trouble"? Particularly for a game, the guts of libraries are a rarely visited place and the long term perspective is another project with its own set of libraries.

Answer 34 · 2023-06-30T08:27:11.000Z

Oh man, this makes Zig suddenly a lot less attractive because integrated C++ and ObjC support is one of Zig's killer features to me. Without that it's "just another better C".

I don't care about LLVM specifically, but about losing C++ and ObjC capabilities with zig cc. Pretty much all of my projects integrate C++ libraries (like Dear ImGui) and on macOS some ObjC code for talking to system frameworks. If I need to suddenly deal with another compiler toolchain to compile this code then it becomes the same mess as other compilers that can't handle C++ and ObjC out of the box.

At least consider including a separate clang executable in the standard Zig distribution, and call that from zig cc, so that we don't loose any functionality from a user's point of view.

Answer 35 · 2023-06-30T08:41:40.000Z

Adding to the choir. We are investigating writing CUDA kernels in Zig (yes, it works) and removing LLVM support would be a massive showstopper. LLVM support (and zig cc/c++) is a big reason why we want to invest heavily on Zig.

It also makes Zig the actual escape hatch from C/C++ for HPC. An area in which Rust still struggles to get into in term of penetration.

Answer 36 · 2023-06-30T08:42:30.000Z

And here I was trying to figure a good way to also get zig lldb going so that a zig toolchain is a one-stop shop for developers.

I'm new to Zig, but the pragmatic acceptance of reality that lead to having 'zig cc' and 'zig c++' come to be is what convinced me to take Zig seriously and consider it as the foundation for a lot work. I'm now reconsidering and likely to put Zig back on the shelf.

But I look forward to seeing how things turn out! I'm pretty sure things will work themselves out for the better eventually.

That one is close to my heart and I would rather write a replacement than expose lldb.

Answer 37 · 2023-06-30T08:48:46.000Z

Hi Andrew, thanks for your thoughts.

Is there an estimate of how much time you or the core team is spending on LLVM related issues?
Can the community help by taking more care of the user issues with LLVM? Writing more guides?

Post 1.0 there is also the question of how to handle LLVM versions. Will Zig need to be frequently updated to work with last LLVM or will it ship with an old LLVM version? Dropping LLVM avoids that question.

Removing LLVM will be a set back in the number of supported target (I'm thinking Nvidia GPU, but I'm sure there are more).

Zig code seems to be easier to optimize than C++ so maybe some custom optimizations could go a long way. Is there someone working on adding some basic optimization passes in Zig?

In general I'm concerned this will set back Zig 1.0 a few years back. Do you think dropping LLVM will help you move faster? Can some of the LLVM associated churn be offloaded ?

Answer 38 · 2023-06-30T09:05:00.000Z

@lorenzogatti

Particularly for a game, the guts of libraries are a rarely visited place and the long term perspective is another project with its own set of libraries.

Exactly, it makes little sense to replicate established popular C++ libraries like Dear ImGui or Jolt Physics in another language, it will always make more sense to use them via a bindings shim to benefit from fixes, optimizations and feature development.

Answer 39 · 2023-06-30T09:36:23.000Z

Just to add another datapoint: We have found zig cc to be an excellent cross-compiler for C++, and we currently ship multiple games (like Baba Is You) using it.

To be honest, my impression was that zig cc was meant to be one of Zig's killer features, so it would definitely be a shame to see it go.

Answer 40 · 2023-06-30T09:37:45.000Z

@slimsag

Many of the comments in this thread are about people using zgui, wwise, zig-gamedev, assimp, and other C++ libraries wrapped with Zig. It gives you a leg up in the short term, but I worry in the long-term that people's gamedev experiences coming to Zig will be 'initially I saw a nice language... then I encountered the guts of the libraries I was told to use were large, clunky C++ codebases'

While this is true, there are other incentives than "removing C++ support" for writing better libraries natively in Zig, so I wouldn't worry much about this. It's expected that this early in the life of a language, the main source of libraries are bindings.
For starters, Assimp and friends are massive dependencies with a lot of historical cruft and bloat, probably subpar performance, some traits that are known to itch the zig community :)

Answer 41 · 2023-06-30T09:42:30.000Z

@kubkon

That one is close to my heart and I would rather write a replacement than expose lldb.

I'm all in favor of that myself and would love to work towards that! lldb was more of a practical matter (liblldb as a place to start). 'zig dbg' could have been the command instead. :D

The complication of python being involved with lldb was kind of mucky anyway. I just thought that it was worth starting from something that exists, learn some lessons, rinse and regroup.

Answer 42 · 2023-06-30T09:42:31.000Z

Assimp and friends are massive dependencies with a lot of historical cruft and bloat...

...but also decades of bugfixes and solid support for even obscure asset file formats. An alternative rewritten in another language will most likely take the same time, but more likely will be abandoned before it reaches the same level of maturity.

I'm not a fan at all of each language being its own library ecosystem island. We should strive for more language interoperability and mixed-language projects, not less.

Answer 43 · 2023-06-30T09:47:18.000Z

I'm not a fan at all of each language being its own library ecosystem island. We should strive for more language interoperability and mixed-language projects, not less.

Amen brother.

Answer 44 · 2023-06-30T09:48:56.000Z

I'm not a fan at all of each language being its own library ecosystem island. We should strive for more language interoperability and mixed-language projects, not less.

Absolutely, my point is that people who want to have pure Zig libraries will always be able to, and that it shouldn't be an argument to drop C++ support.

Answer 45 · 2023-06-30T10:33:03.000Z

I guess I'll be staying on the last version before the drop of LLVM, since that's the main feature I wanted from Zig: Cross-compilation of C++ projects using a build.zig.
Hoping for a replacement or fork once it starts misbehaving or getting incompatible after some year, to get LLVM upgrades.
Having this dual zig/c++ capable compiler with easy interop without writing wrappers, was the best kind of way to get people into Zig. Though, I'm just repeating the sales pitch from the official Zig page now.

Answer 46 · 2023-06-30T10:37:10.000Z

This is the beginning of the end of the LLVM 🔥🔥🔥

Answer 47 · 2023-06-30T10:37:24.000Z

As others have mentioned, C++ compilation is a major selling point of zig and it would be a shame to lose that. However, there are meaningful benefits to removing llvm from the default distribution.

Perhaps it would be possible to split llvm dependencies into a zig package that can be added to a project's build system using the package manager. This way, C++ compilation and llvm-based code generation could be added to projects that need it, without increasing the size of the core zig binary.

Answer 48 · 2023-06-30T10:47:02.000Z

I'm very much against this proposal. Not only will runtime performance suffer greatly without LLVM, but the number of targets will drop significantly too. You'd also lose any sort of C/C++ cross-compilation support, and the ability to compile anything other than C code in a Zig project. Especially those last 2 points are big advantages of Zig, at least, in my opinion.

And now, instead of embracing LLVM and trying to improve its code generation and report bugs, we'll now be competing against it. And that is definitely not the right way of doing things.

In my opinion, the size of the Zig compiler binary doesn't really matter. If it went from something like 1 GB to 100 MB, yes, that would've been significant, but 150 MB really is nothing today. Also, I'd rather have slow compilation speeds but very good runtime performance than the opposite.

And, finally, while I'm not trying to be pessimistic, I don't think you guys will be able to compete with LLVM's code optimization, at the end of the day. LLVM is a massive project that took years to develop and is still being actively improved, while you guys want to start a whole new IR with code optimizations.

So, in my opinion, I don't think this proposal is a good idea. Instead, we should keep things as is and continue to embrace LLVM like we already are.

Answer 49 · 2023-06-30T11:00:26.000Z

If there's a way to do it without killing support for the tier 1 targets, I'm all for it.

Answer 50 · 2023-06-30T11:10:37.000Z

And here I was trying to figure a good way to also get zig lldb going so that a zig toolchain is a one-stop shop for developers.

I'm new to Zig, but the pragmatic acceptance of reality that lead to having 'zig cc' and 'zig c++' come to be is what convinced me to take Zig seriously and consider it as the foundation for a lot work. I'm now reconsidering and likely to put Zig back on the shelf.

But I look forward to seeing how things turn out! I'm pretty sure things will work themselves out for the better eventually.

I can definitely see where you are coming from, but dismissing Zig over a proposal seems pretty extreme ...

Answer 51 · 2023-06-30T11:13:36.000Z

I am fully in support of this proposal.

The C++ capabilities should be removed ASAP IMO because compatibility across C++ compilers is basically non-existent and its better to rip the bandaid off sooner than later.

I think this proposal suggests replacing all the relevant bits LLVM brought in before cutting it off, I'd be interested in seeing a compile time option to remove all the LLVM bits ahead of time to see how it would perform.

Answer 52 · 2023-06-30T11:26:24.000Z

You can't implement what you will miss with a plugin that can be installed for those who want to have it?

Answer 53 · 2023-06-30T11:40:11.000Z

What concerns me a little about this proposal is that it looks like quite a bit of work has already gone into implementing it, before it ever made it to the public. Which is something that should never happen, especially not when the subject is as fundamental as this.
Makes me think that some changes to how the core team communicates with the community might be in order.

EDIT: Not the case at all, see replies bellow.

Answer 54 · 2023-06-30T11:50:01.000Z

What concerns me a little about this proposal is that it looks like quite a bit of work has already gone into implementing it, before it ever made it to the public. Which is something that should never happen, especially not when the subject is as fundamental as this.
Makes me think that some changes to how the core team communicates with the community might be in order.

No work has been done on this proposal at all. The checklists in the issue are about removing our hard dependency on LLVM (since that's a prerequisite for its removal), which has been a publicly-known plan for years with many benefits and zero downsides. Work on eliminating LLVM support has not started.

Answer 55 · 2023-06-30T11:57:56.000Z

In support of this proposal:

Most modern languages do not directly compile C++, but can still interface with it. I don't think it's important if zig actually does the compilation or not, as long as we can still use C++ libraries.
Zig already does a lot of solid foundational work most other langs avoid by piggybacking on existent tools. Doing more foundational work sounds reasonable.
This is in line with the overall mission set out by Andrew and crew, that of improving programming environments overall, not just of writing a language.

However:

"Maintain it with Zig" was a major selling point. This apparently walks back on a core promise which is advertised on the homepage.

Is there a path where zig loses the capability to build C++ projects directly, but build.zig continues to support this? Even if it relies on a system installed LLVM or requires downloading an optional component besides the (new) 5 MiB compiler? I love that I can get rid of CMake (& co.) today with zig, I love that I can cross compile, I however don't care that LLVM is used by zig. All I care is "zig has bindings for all libc versions, and knows how to get my existing libraries to work on any target". No other build system knows how to do that well. And "damn, my build system is so much easier to use". Can we keep that if this proposal goes through?

[TLDR] Can we keep the nice cross platform features and usability we have today with the zig toolchain, not the zig compiler per se? Even if it integrates with an external optional component if we need it to build C++ code?

Answer 56 · 2023-06-30T12:08:00.000Z

Another data point, which the core team knows pretty well about: https://github.com/uber/hermetic_cc_toolchain is built on top of zig c++ which is used to compile "lots of C++".

I have no opinion about the back-end for the zig code, but do have an opinion on zig c++ for (x86_64|aarch64)-linux: if Zig loses zig c++ the way it is offerred now, it will be difficult to rollback and/or move elsewhere: there is nothing that good in the industry as zig c++ is today.

I hope we can find some middle-ground which keeps zig cc/c++ with LLVM backend, but in a way that disrupts Zig developers less than it does now.

Answer 57 · 2023-06-30T12:14:27.000Z

This is a great idea and I hope it works out. Zig could use some debloating and an improvement to compile times.

Answer 58 · 2023-06-30T12:18:23.000Z

Even if libllvm/libclang gets removed as a build-time dependency of zig, it would be amazing if zig build could shell out to a clang executable for the step of turning .cpp files to .o files, to use zig build as a build system for c++ dependencies, including passing all the flags to clang needed for the use for cross-compilation.

Understandably, that would likely require up-streaming improvements to the native clang driver to be fully usable in a cross-compilation context. Such a contribution to clang would be a worthy effort regardless (regardless if done by zig members or third-party contributors)

Answer 59 · 2023-06-30T12:22:27.000Z

What concerns me a little about this proposal is that it looks like quite a bit of work has already gone into implementing it, before it ever made it to the public. Which is something that should never happen, especially not when the subject is as fundamental as this.
Makes me think that some changes to how the core team communicates with the community might be in order.

No work has been done on this proposal at all. The checklists in the issue are about removing our hard dependency on LLVM (since that's a prerequisite for its removal), which has been a publicly-known plan for years with many benefits and zero downsides. Work on eliminating LLVM support has not started.

That's good. Might be worth clarifying that than, because it's not at all obvious from the wording of the initial post.

Answer 60 · 2023-06-30T12:22:41.000Z

First and foremost, the Zig compiler should be able to compile Zig source code in the best possible way, without any restrictions. If it can also compile other source code, that's a nice feature, but not a necessity.

Besides, Zig has set out to be the better C. Therefore the biggest focus should be here and not in additional languages. Especially since C++ is definitely not C. Also not Rust or Fortran, Python, whatever.

Maybe one or the other thinks about getting directly involved with the respective language instead of insisting that everything has to be covered by Zig. Because that just limits Zig and doesn't lead to becoming the best language ever, which is what I strongly hope for.

From there I support Adrew's proposal one hundred percent and think for the now listed (xx, yy, zz)-projects a suitable solution will be found.

Answer 61 · 2023-06-30T12:27:21.000Z

Are you gonna use cranelift then? That would be great!

Answer 62 · 2023-06-30T12:29:54.000Z

@berkus I think it's acceptable only after performing RIIZ on Cranelift. Could you please create an issue about that in the Cranelift upstream?

Answer 63 · 2023-06-30T12:36:28.000Z

@chrboesch

If it can also compile other source code, that's a nice feature, but not a necessity.

That's... literally one of the sole reasons Zig exists??!!

Answer 64 · 2023-06-30T12:40:57.000Z

I think we should divided into 3 parts:

linker/binutils components and c fronted. This is easy to replace and can replaced ASAP.
LLVM for codegen, Regression here for quite sometime. Solveable still
Clang used by build system to handle c++ and obj-c. This is a regression although not a severe as LLVM side, still a regression esp since its an advertised and seems to be a feature that sells people to zig.

Once x86, arm and wasm targets are covered, point 2 can be made opt in. Remove 3 will stunt growth of zig and can kill its momentum. But looking at the fact ripping it out is a good idea due the issue in the OP, I think the middle ground is to make clang and llvm components optdeps that are only used if available at runtime. I am leaning to moving to make it work in plugin land since now we have a package manager in zig and we can call external binary if placed in the PATH so we can simply say, if need c++ and obscure arch support, install this extra package too. This is probably the best middle ground I can think of unless Zig wants to go dlopen plugin route

Answer 65 · 2023-06-30T12:42:53.000Z

Are you gonna use cranelift then? That would be great!

No. Zig already has their own code generator used by C and LLVM backend. Just that bare metal targets are still WIP although a couple are near completion (80%+ test pass).

Answer 66 · 2023-06-30T12:45:26.000Z

@berkus I think it's acceptable only after performing RIIZ on Cranelift. Could you please create an issue about that in the Cranelift upstream?

Did you really mean RIIR on Zig?

Answer 67 · 2023-06-30T13:10:37.000Z

This news really makes me sad.

On the one hand, I completely understand the reasons. LLVM is a huge elephant to swallow and changes version to version can break Zig— I get it.

On the other hand, having a single binary with all that cross-compiling ability for Mac/Windows/Linux is the main reason I gave Zig a look in the first place. One compiler binary with sane defaults, and I can move parts of an app to Zig or write a new Zig app on top of c++ libraries. The videos every year convinced me.

I was about to push to use Zig on a new project at work and this news is making me rethink. The worst part? There’s no replacement. No other “new” language has this benefit. It is unique to Zig and losing it would be a major blow.

Answer 68 · 2023-06-30T13:14:04.000Z

It might be worth clearing up some common questions. I assume this means no more "zig cc", etc?

This seems like a very poor decision, and makes little sense after your talk at GOTO.

Also, linking to C code that has different signatures when compiling can be a real pain, especially with precompiled DLL's. So having to build this sort of system from scratch... I assume this hurts Zig C interop substantially as well?

I don't dislike the idea of a pure compiler. But I don't think there is any merit, especially at this stage (with 0.11 (ZERO point ELEVEN) barely out the door).

But a modular design for the compiler. I.e. as a (default) optional addon to the zig compiler (maybe make IR / backends sort of like plugins) would be interesting.

But LLVM needs to stay supported until you have anything better than it. Which I doubt will be anytime soon.

Answer 69 · 2023-06-30T13:17:54.000Z

I hope zig cc and zig c++ remain after all this.
Using build.zig for both Zig and C/C++ is pretty awesome too.

Answer 70 · 2023-06-30T13:22:49.000Z

I think it's very premature to remove LLVM support in 1.0.0.

I don't want to discredit the arocc and zld project (it needs more contribution that are few compared to zig).
However, they do not provide the same support level that zig already provides for the toolchain.

Especially for C++ zig toolchain allows unifying C++ABI (libc++) + C++EH ABI (libunwind) in almost all LLVM targets. This is very hard compared to other tools available today in this area.

Earlier, at the old zig forum (ziggit's predecessor), when informing of my interest in the project, I wrote that "zig is convenient". Convenience many times does transcend by necessity though not the best.

I don't disagree that it is an overhead for those developing a compiler and/or toolchain. However, the alternatives need improvement to keep up with current support conditions.

I don't have large projects, most of them are tests derived from C++ code (including porting boost libraries to zig-pkg). The zig package manager in the upcoming version (even simplified) is going to be another attractive feature for developers.

https://github.com/kassane/xwin-zig-test - Zig toolchain replacing msbuild
https://github.com/catdevnull/awesome-zig#cc-libraries-packaged-for-zig - C & C++ libraries using zig-pkg.

Answer 71 · 2023-06-30T13:39:37.000Z

Assimp and friends are massive dependencies with a lot of historical cruft and bloat...

...but also decades of bugfixes and solid support for even obscure asset file formats. An alternative rewritten in another language will most likely take the same time, but more likely will be abandoned before it reaches the same level of maturity.

I'm not a fan at all of each language being its own library ecosystem island. We should strive for more language interoperability and mixed-language projects, not less.

Totally agree with that.

I think losing the C++ compilation capability that is advertised will hurt a lot of projects and reduce Zig adoption. As a gamedev, having the capability to compile Zig, c, c++ is top priority because a lot of libraries are in c/c++ language and Zig build capabilities ease this process.

I think we should to rethought this or at least provide a viable alternative to not lose this capability.

Answer 72 · 2023-06-30T14:23:13.000Z

A very long, long time ago was asking for C to be a primary target of zig and it is nice to see it getting traction after all! :-) THX @andrewrk

Answer 73 · 2023-06-30T14:46:44.000Z

Zig is not 1.0. A non-LLVM Zig enables Zig to be better specified, leading to alternative implementations.

@chrboesch expressed it well.

Knowing the Zig community, they will get output as fast as LLVM before anyone actually realizes. There are passionates with time on their hands working at this night and day.

I feel sorry for the C++ users. Unfortunately you chose C++. Improve your ecosystem of choice. There are no problems dynamically linking with Zig.

Really the people complaining the most appear to be industry users. Guys, this is not 1.0.

Answer 74 · 2023-06-30T14:59:51.000Z

Knowing the Zig community, they will get output as fast as LLVM before anyone actually realizes. There are passionates with time on their hands working at this night and day.

Making an IR with optimizations is much, much more difficult than you'd think.

I feel sorry for the C++ users. Unfortunately you chose C++. Improve your ecosystem of choice. There are no problems dynamically linking with Zig.

The way I interpret this is "Oh, you chose C++? Then go fuck yourself, haha.". And this is obviously wrong. We should make C++ developers want to use Zig, not make them run away from it (and potentially every other language as well).

Answer 75 · 2023-06-30T15:09:20.000Z

Making an IR with optimizations is much, much more difficult than you'd think.

What's your goal in mentioning this in a thread full of people that are completely aware of this? We all know how hard it is. To me this implies you are not aware of the expertise and efforts made by the people working on Zig.

The way I interpret this is "Oh, you chose C++? Then go fuck yourself, haha.". And this is obviously wrong.

Not at all. But C++ users are not using Zig the language. They're using the tooling. C++ is still their primary language and will continue to be. I don't know what else to say. I actually do feel sorry because it sucks but it's the hard reality.

Answer 76 · 2023-06-30T15:20:39.000Z

Making an IR with optimizations is much, much more difficult than you'd think.

What's your goal in mentioning this in a thread full of people that are completely aware of this? We all know how hard it is. To me this implies you are not aware of the expertise and efforts made by the people working on Zig.

The way I interpret this is "Oh, you chose C++? Then go fuck yourself, haha.". And this is obviously wrong.

Not at all. But C++ users are not using Zig the language. They're using the tooling. C++ is still their primary language and will continue to be. I don't know what else to say. I actually do feel sorry because it sucks but it's the hard reality.

What are you talking about? Stop with you preconceived ideas of what you think others use.
This is a proposal, so stop with your "sorry because sucks" , "you use c++? fuck you" because this adds nothing to the proposal.

Speaking as a gamedev, I use Zig for the game and engine code, the only code I write is in Zig and I want to use ONLY Zig BUT I use too the zig c++ compilation capabilities to build and interoperate with libraries like imgui that are very useful and are in c++.

Answer 77 · 2023-06-30T15:21:26.000Z

Not at all. But C++ users are not using Zig the language. They're using the tooling

Yes, and the Zig build system serves as a great build system even for C and C++. In my opinion, this feature should be kept, as it is a strong point of Zig.

Answer 78 · 2023-06-30T15:21:44.000Z

Not at all. But C++ users are not using Zig the language. They're using the tooling. C++ is still their primary language and will continue to be. I don't know what else to say. I actually do feel sorry because it sucks but it's the hard reality.

This seems like a bizarre assertion to make in a thread where multiple people have explained that their use case is writing a program in Zig that depends on some C++ libraries.

Answer 79 · 2023-06-30T15:42:47.000Z

This is a proposal, so stop with your "sorry because sucks" , "you use c++? fuck you" because this adds nothing to the proposal.

Well sorry for having some empathy. Jeez. ~~How revolting.~~ Sorry, it's just frustrating to read this.

Stop with you preconceived ideas of what you think others use.

I'm going purely based on this thread and it appears a lot of people are using Zig for its tooling! I guess my perception is entirely wrong.

Speaking as a gamedev, I use Zig for the game and engine code, the only code I write is in Zig and I want to use ONLY Zig BUT I use too the zig c++ compilation capabilities to build and interoperate with libraries like imgui that are very useful and are in c++.

This seems like a bizarre assertion to make in a thread where multiple people have explained that their use case is writing a program in Zig that depends on some C++ libraries

And many explained their use case is using the Zig tooling...

"Using Zig to compile C++".

It really seems absurd to think it should be Zig's responsibility to compile C++.

But C++ users are not using Zig the language.

Yeah ok, this stepped over a line and not well communicated. I didn't mean this to be interpreted as a universal statement.

It's pretty clear at the end of the day, we all really love Zig :D.

Answer 80 · 2023-06-30T15:45:55.000Z

It really seems absurd to think it should be Zig's responsibility to compile C++.

In my opinion I think it should be, at least when it comes solely to the build system (which, at the end of the day, is integrated into the Zig compiler). And, by this logic, according to you, it shouldn't be Zig's responsability to compile C either... which, in my opinion, is very useful. Imagine wanting to rewrite parts of your C or C++ project in Zig without having to rewrite everything. That's just amazing!

Answer 81 · 2023-06-30T15:48:51.000Z

And many explained their use case is using the Zig tooling...

"Using Zig to compile C++".

The issue is that you made a broad generalization that doesn't hold even just within this thread.

It really seems absurd to think it should be Zig's responsibility to compile C++.

It very much isn't absurd when Zig has been advertised as doing exactly that (see my earlier comment). You can certainly argue that this was a mistake from the beginning, but that's a different argument.

Answer 82 · 2023-06-30T15:49:08.000Z

it says to me that supporting LLVM, while useful, is adding a huge amount of bloat to the Zig project, and Zig has never been known to tolerate bloat (which I love).

Sure, but that's just in the compiler itself, not in the final binary. Besides, while sure, it does reduce the binary size of the compiler quite significantly, going from 150 MB to 5 MB isn't worth it in my opinion, because 150 MB just isn't much by today's standards.

Answer 83 · 2023-06-30T15:57:55.000Z

It very much isn't absurd when Zig has been advertised as doing exactly that

To me this is the biggest problem with the whole situation truly. Since Zig "promised it", and now is "going back on the promise", there is now of course a massive rift. And I can only completely agree and the only reasonable recourse I can say is "it's not 1.0, so you should have expected it" (not that it's a solution to the problem though).

The issue is that you made a broad generalization that doesn't hold even just within this thread.

Yeah I understand, thanks. Didn't mean for it to be broad, but it's the gist of what I got from reading the thread. I'm assuming most people have some Zig code, but the rest is mostly a C++ behemoth. Even if my assumption is right, it's still wrong of me to say choosing C++ was a choice. It may be better for me to say choosing Zig was the wrong choice, because it was an actual choice, but given the promises... yeah. Boy what a doozy.

Luckily as a Zig user who just dynamically links to other projects it's not a problem, but I hope a solution is found in some form for the others. I can imagine industry stepping in here to provide the maintenance effort for an external tool...

Answer 84 · 2023-06-30T15:58:52.000Z

Pass by here from hacker news.

We can implement our own optimization passes that push the state of the art of computing forward.

As a not-very-experienced compiler engineer, I was just wondering if there is any plan for what passes will be implemented, to meet this goal.

I didn't go through every LLVM's middle-end optimization pass, but I do think a lot of them should be needed too, reimplementing them doesn't sound like an easy job.

Answer 85 · 2023-06-30T16:01:17.000Z

My 30+kloc game written in D fully recompile in 0.6 seconds on my linux machine, the compiler executable is only 7mb

Similar to my Go server

Just to open a window and render some triangles, zig already struggle to compile my project, it takes 1.6sec each time i change a constant, hence why i postponed my use of zig until that story improves

https://github.com/ryuukk/zark (3 years ago)

I support this idea of getting rid of LLVM, it not worth it in the long run, do like what D did, and maintain your own stuff, the more dependencies you add, the less in control you are, and you'll have to sacrifice things as a result hence why your post

Answer 86 · 2023-06-30T16:03:20.000Z

I fully understand if the zig team want to have a llvm-free core compiler, but I really hope there is a way for the zig build system to support the following things even if this proposal is accepted:

compiling a zig program for mac that contains a bit of obj-c code
compiling a zig program that depends on a c++ library
cross-compiling a zig program that depends on a c++ library
have a well working zig package manager that can package c++ libraries together with a zig wrapper for the library
never have to write cmake-files again :)

Answer 87 · 2023-06-30T16:14:22.000Z

As the person who has promoted the use of zig cc at Chipflow and has recently completed the migration of all C/C++ compilation to use zig cc, I am disappointed to learn of this decision.

From my personal perspective, zig cc was the single most unique and competitive feature the Zig project had to offer, unmatched by any other programming language toolchain.

From my perspective as a maintainer, I hope someone forks and/or rewrites ~~in Rust~~ the code powering zig cc so that it can continue to evolve as its own project. I also hope this someone wouldn't be me, but if I have to, so be it.

Answer 88 · 2023-06-30T16:15:50.000Z

As the person who has promoted the use of zig cc at Chipflow and has recently completed the migration of all C/C++ compilation to use zig cc, I am disappointed to learn of this decision.

No decision has been made. This is a proposal that is neither rejected nor accepted at this stage.

Answer 89 · 2023-06-30T16:16:17.000Z

As the person who has promoted the use of zig cc at Chipflow and has recently completed the migration of all C/C++ compilation to use zig cc, I am disappointed to learn of this decision.

From my personal perspective, zig cc was the single most unique and competitive feature the Zig project had to offer, unmatched by any other programming language toolchain.

From my perspective as a maintainer, I hope someone forks and/or rewrites ~~in Rust~~ the code powering zig cc so that it can continue to evolve as its own project. I also hope this someone wouldn't be me, but if I have to, so be it.

Just to make sure it’s clear, this is an unaccepted proposal. It may or may not happen, or it may take a very different shape than what is currently outlined when all is said and done.

Answer 90 · 2023-06-30T16:16:56.000Z

As the person who has promoted the use of zig cc at Chipflow and has recently completed the migration of all C/C++ compilation to use zig cc, I am disappointed to learn of this decision.

To be clear, this is not yet a decision, it's a proposal. It will undergo heavy discussion before a decision is made. (dammit two other people said this before i could hit comment)

From my personal perspective, zig cc was the single most unique and competitive feature the Zig project had to offer, unmatched by any other programming language toolchain.

zig cc isn't going anywhere, we just won't be using Clang for it - see #16269. It's C++ compilation which is the main discussion point at the minute.

Answer 91 · 2023-06-30T16:17:55.000Z

Just to make sure it’s clear, this is an unaccepted proposal. It may or may not happen, or it may take a very different shape than what is currently outlined when all is said and done.

Ah, thank you. It wasn't immediately clear from the text of the issue that speaks of this outcome with a finality. Perhaps a reminder in the issue text itself would be helpful? Especially seeing as this issue is gaining traction on social media.

Answer 92 · 2023-06-30T16:23:34.000Z

Very unfortunate news. In my opinion zig c++ is the best cross compiler currently in existence and it had a very bright future ahead of itself…

Answer 93 · 2023-06-30T16:23:40.000Z

zig cc isn't going anywhere, we just won't be using Clang for it - see #16269. It's C++ compilation which is the main discussion point at the minute.

I'm particularly interested in building CXXRTL simulations, which heavily rely on the C++ compiler to instantiate arbitrary width arithmetics at compile time and then on the LLVM optimization passes (specifically; while GCC and MSVC work, LLVM is the recommended optimization engine as it has the best performance) to clean the result up. It was a very effective way to do 1% of work that went into Verilator to get 90% of the performance, and I'm keen on keeping it.

Answer 94 · 2023-06-30T16:36:48.000Z

What @ryuukk left out, is that D has three different compiler backends for the same frontend. Each compiler gets its own glue code, some minor syntax changes (like inline assembly), and some druntime additional modules.

The compiler backend (dmd's) that they use, is not really recommended outside of development and even then it's a 30+ year old backend that can do bad things.

We strongly recommend LDC (LLVM) if you care about correctness or performance.

This situation is a great compromise. It allows people to pick what suits them the best and allows the feature sets and targets supported to vary between compilers. This could be the way forward for Zig as well, especially since there are commercial users here saying that this would be a "new language-level event" for them.

Answer 95 · 2023-06-30T16:42:12.000Z

Seems like it could be possible to adapt LDC or whatever backend to the interface zig ends up using for that.

Answer 96 · 2023-06-30T16:55:40.000Z

But C++ users are not using Zig the language. They're using the tooling. C++ is still their primary language and will continue to be.

@lf94 that's not true, I would like to get rid of C++ in all of my projects and just use a mix of Zig and C, but there are critical libraries that are only available in C++. If I need to use a separate C++ compiler and build system to build those dependencies, then Zig is the same hot mess as other languages (like Rust).

Answer 97 · 2023-06-30T16:58:01.000Z

zig cc isn't going anywhere, we just won't be using Clang for it

@mlugg I think most people just use zig cc as synonym for the clang frontend, no matter if it's used to compile C, C++ or ObjC (PS: there's also value in the fact that it is specifically clang, and not a self-rolled strictly standard compliant C compiler frontend: Clang comes with a ton of useful non-standard extensions (like the vector stuff) that are not part of the C standard, yet Clang is big and popular enough to make it worthwile using those extensions in a C code base).

Answer 98 · 2023-06-30T17:09:54.000Z

If zig itself get rid of clang, I strongly suggest there's another standalone, official project that bundles clang and support the existing use case of building C++ code.

zig being a painless c++ toolchain which also handles cross compilation is such a great idea and attracts a lot of good attention, which is pity to lose them.

Answer 99 · 2023-06-30T17:56:01.000Z

2 cents.

If this is a breaking change, then it is probably adequate to make a migration tool for the codebases that depend on the features this would dispose of.

If that can't be done, I don't see how this wouldn't split the Zig codebase.

Answer 100 · 2023-06-30T18:13:25.000Z

Several people have suggested splitting out a separate tool. To make a concrete proposal:

zig is a small executable that can compile zig projects, install zig packages, translate c headers and output native code or .bc
zig-cc is a tool that can be installed via the zig package manager (or downloaded separately) and supports cross-compilation of c/c++/objc/.bc

This achieves some of the goals. Certainly the compiler architecture would get simpler. Bootstrapping and incremental compilation would get easier. Mixed zig/c++ projects would still benefit from easy cross-compilation. The bc backend would provide high quality codegen while the native zig codegen catchs up.

But zig-cc would still be a large maintenance burden for the core team. Perhaps the ideal resolution would be for some of the companies that depend on it to get together and employ a maintainer, freeing up the core team for zig-specific work.

EDIT Obviously this comment should be titled "File for divorce but don't throw out the baby".