This proposal has created quite the discussion on github and I thought it would be appropriate to bring that discussion here to forum. Here is a highlight from the proposal that seems to be garnering a lot of attention/concern:
This will remove C++, Objective-C, and Objective-C++ compilation capabilities
from Zig. 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.
However, there is also this:
Note that there would still be an LLVM backend for outputting .bc files (#13265),
but the Zig compiler would lack the capability to compile .bc files into object
files. LLVM or Clang would need to be installed and invoked separately for
that use case.
Some commonly cited benefits include:
Less dependency on outside systems where Zig does own the ability to resolve bugs.
Drastically smaller compiler binary and increased compilations speed.
Resolving existing and persistent problems with package managers.
Potentially more target platforms being supported.
Some common concerns voiced about the proposal are:
The observation that this goes against what has been advertised.
The importance of integration with existing code (even for promoting further Zig usage itself).
Concerns about the feasibility of creating a replacement for LLVM.
Suboptimal machine code would gravely injure the reputation and usability of Zig.
Exciting times we’re living in. I’m still formulating my opinion on this because I was preparing to write an extensive cuda backend for a project I am working on. It seems like that may still be possible, but that an outside dependency on Clang would be in order and a separate step in the build process would be also required.
I’m far from knowing all the ins and outs of this issue, but as a gross oversimplification in my mind, I think this is a necessary step, albeit a strong growing pain in Zig’s evolution. It’s freeing itself from a big dependency that on one hand is providing a lot of useful functionality and optimizations right now, but on the other hand is currently and will continue to hinder compilation speed, compiler size, and the ability to fix bugs rapidly in-house versus depending on someone else to do it later. Without this huge dependency, I think Zig can evolve faster, and I have no doubt the core team and contributors can ultimately surpass what LLVM and GCC can do today. The big question is how long would that take? And how many users are willing to take the hit now and wait for a better tomorrow?
Also, as the Zig build system is becoming more and more powerful, wouldn’t it be a matter of adding steps to invoke LLVM / Clang as external tools in projects that need these dependencies? This would have the added benefit of not requiring projects that don’t need these dependencies pay for them. Like the C++ zero-overhead principle of “you don’t pay for what you don’t use.”
I’ve been keeping an eye on Zig even while not actively using it as much as I used to. I think there is an awful lot of jumping to conclusions about what this proposal might actually mean. I also think that I trust Andrew, based on what I’ve seen him pull off in the past. The idea of pulling off code generation and optimization for all of the desired platforms sounds daunting now, but then therecent dramatic decrease in memory used during the compile of Zig itself (11.3G down to 3.8G!) definitely makes me want to see what other miracles are in store. reference
I doubt that Andrew is going to move on this if the community continues to be as negative about it as what I saw in the GitHub thread, but it just may be to everybody’s detriment in the long run if the safe path winds up being the one taken. I kind of want to see the outcome of “go big or go home” in this case.
This does mean that the the burden of dependencies gets shifted to the user. Honestly, I don’t mind that. I have had more problems with package managers assuming things about my system and then installing secret versions of crap everywhere and then linking to the wrong binary files… NVIDIA’s shared object libraries made me rage-quit on several occasions.
I’m genuinely torn on this point. My disheveled-developer mind says “yeah, screw it - don’t hang onto these dinosaurs” while my been-there-done-that-engineering brain says “don’t fix what ain’t broke”. Don’t know who to trust here.
I want to bring up an interesting point here though - it comes from a quote where @andrewrk was talking with Jason Turner about this exact issue (quote at 28:02 - 29:27) on this video: https://www.youtube.com/watch?v=AdP6seB4sp4
During that time segment, @andrewrk specifically says that a small team of developers cannot match the abilities of LLVM. Paraphrasing, he says that he believes they can get 80% of the way there, but that last 20% of performance he says (direct quote) “it’s not going to happen”.
I really want to know if he still holds this view and if not, what changed his mind? Because in the proposal, it says “Long-term, it may catch up or even surpass LLVM and GCC.”
I’d like to see some more commentary on this discrepancy. I don’t believe he is contradicting himself (I’m not interested in some silly “gotcha” moment) but I think there has been a change of mindset that I haven’t seen communicated.
I think keeping C++ and Objective-C compilation capabilities is a must, one way or another.
On the other hand, I would definitely love it if Zig ditched LLVM, and “owned” all of its own tools and bugs.
As such, my opinion is that Zig should keep LLVM around as the default, while working on the tooling to eventually replace it, the same way things currently are, only with the eventual goal of actually removing LLVM altogether. I don’t know a ton about compilers, but I don’t think the issue of optimization passes will be TOO big of an issue. AFAIK, backends like QBE claim to “to provide 70% of the performance” of compilers like LLVM & GCC in “in 10% of the code” — so maybe the speed regression won’t be as terrible after some work is put in here, but then comes the remaining 30% that’ll be needed for applications hoping to squeeze out every bit of performance.
I’ve never really taken a look at Objective-C, and just know it has something of a light runtime, and that Swift interacts with it, but I imagine it probably wouldn’t be too taxing to write a compiler for it in Zig. The real issue would be C++. Even a parser for it looks like a daunting task.
Aro was developed off in its own repo, so a C++ & ObjC compiler would probably be the same, but I think to ease this process, a good idea might be to split off the code for the custom backend into its own repo separate from the main Zig repo, so that it can be imported as a package via the Zig build system. In said package, there would be the so-called “Contributor-Friendly IR” mentioned in the github issue, and the codegen code for transforming that into the appropriate machine code for each platform. This could then standardize the process of upstreaming these languages into the main Zig repo—or keep them as separate repos entirely that can be used as libraries, either by Zig itself, or by Zig users that need C++/ObjC in their respective projects.
While I’m glad he clarified his intention, one nitpick that I think is helpful here: the title of the proposal really put it on a bad foot to begin with.
I get that it’s a joke (and I took it that way) but the word divorce is a pretty strong sentiment. I think if it had been titled “Consider replacing LLVM in the long-term” instead of “File for Divorce from LLVM”, you may have had less misunderstandings upfront. You have to admit, the original sentiment sounds more like a direct certainty than a set of considerations being proposed.
I agree, the misinformation & hysteria that the issue generated is overall a net negative in my opinion. That said, it’s annoying having to constantly have to keep in mind public relations when communicating with contributors. Within the core team (and other people involved in the development of Zig) we’ve had plenty of discussions about getting rid of LLVM one way or another, so this is nothing new.
I like the proposal, even though I use zig c++ to compile C++ deps in my Zig library. I think the capability to compile C++ and ObjC/++ could be done via the Zig package manager downloading the necessary tooling.
So a workflow goes from:
To build the project:
git clone project
cd project
zig build
To something like:
zig fetch zig-c++ # if not installed already
git clone project
cd project
zig build
I guess this is yet another ugly aspect of the open source game. An extra burden, but hopefully doesn’t get in the way of fast and effective communication.
A potentially useful community cultural norm here is to avoid directly linking controversially-sounding issues/PRs, and instead link read-only mirrors, like this. This can somewhat cut down on the number of drive-by “I also have an opinion” comments.
No need for the hypothetical zig fetch zig-c++ step. The zig build system is powerful; packages can contain executables (such as clang) and create build artifacts!
I already kinda do this in ffmpeg. It has a dependency on nasm for converting some assembly files into object files.
I hadn’t thought about just packaging up the executable. Tho, in your ffmpeg case, it looks like you also end up building nasm from source (at least the first time?) and for something like clang which is written in C++, I suppose the package would need to have the binaries be pre-compiled for every target platform it’s expected to be used on? (the way Mach has Dawn pre-compiled, to save on compile time) + any libc++ headers as well.
I think this would be a good route to take. If the ZSF could host a clang package that wraps the clang executable with a Zig API that can interact with the Zig Build API types, then I think it would be a good substitute for the current C++/ObjC uses, at least until a C++/ObjC compiler can make its way into Zig proper (if ever)
Although, this still leaves out those who want to use zig cc as a drop-in replacement for gcc/clang, without having to write a build.zig for their projects.
I, personally, see this as a downside of being on Github specifically. Everybody in the universe generally must have a Github account for some reason so it’s too easy to fire off a drive-by comment.
From what I have seen, the extra friction of being on somewhere other than Github (Gitlab, sr.ht, anything) and only using it as a read-only mirror cuts down dramatically on the peanut gallery.
As for the technical idea? The sooner, the better. Zig needs as few obstacles as possible to being as cooperative within and without its own ecosystem as it can be.
By contrast, C++ is a pox upon the entire programming space and support for it should be quarantined as much as possible. Nobody can agree on which subset of C++ is reasonable. Nobody can agree on build tools that don’t seem to suck. Python and Rust people are constantly tying theselves into knots trying to interoperate with C++ in a way that doesn’t simply throw out everything except a C ABI level. And even C++ people gave up on trying to cooperate and started creating “header-only” libraries to sidestep all the incompatibilities within the ecosystem.
I’m hoping that the WASM/WebAssembly component model work will finally break the compatible C API/incompatible C++ API logjam between languages. We’ll see.
Something that I find distasteful is that after Andrew’s comment on the tracker, in which he specifically reminded people that the tracker is for technical discussion and asked them to stop polluting the thread, several people called him out for initiating the hysteria in the first place in that same thread.
I , personally, see this as a downside of being on Github specifically
Yes, this. And the social media influenced design cues and features on Github really tend to reinforce the same types of behaviors that you see on social media, too. But I don’t want to hijack the thread so I’ll stop there.
Hello, as long as there are fundamental libs like regex, or mpdecimal — mpdecimal project etc… the links with C/C++ must be kept,
rewrite the postgresql package!!!
maybe i misunderstood
To have a pure ZIG compiler, I think you have to write in zig-lang and forget about C/C++ except for links with libs.
It also includes that ZIG is doing what CLANG or GCC does (LLVM)
from what I’ve read, that’s the goal, freedom is something difficult to achieve implies not being afraid to review your copy, IF it goes in this direction, it’s a great thing.
Seeing the clarification in that thread, I’m all on board. The optional clang package seems like a very good solution to compiling existing C++, Objective-C, etc projects without including it in the main executable.
Most projects are only going to need to compile Zig and possibly C code, so there’s no point in packaging clang and LLVM in the main Zig package. Zig only being around 5MB would be pretty incredible
I want to share my thoughts on this topic. I believe that Zig’s build system, together with the package manager, can effectively handle the LLVM toolchain on its own, while maintaining a smooth developer experience™ with the zig build command. It would be a great goal to achieve while working on improving the package manager.
However, I’m a bit unsure about the behavior of commands like zig cc, zig c++, and others outside of the build system. Any insights on this?