Not to criticise on FOSS, but why should the user write their own software again? What's wrong with just paying for it? I'm a huge fan of free software, just don't really understand your comeback.
Hopefully he can find a way to fix the problem of broken models due to invalid vertex/edge references on fillets/chamfers/etc.. when changing features.
This is a problem even script based programs cadquery/declaracad don't really solve.
Im guessing you'll have two categories of tier 1 support:
- Built-in tier 1 support.
- Tier 1 support through the optional LLVM backend.
If they already have tier 1 support for an architecture, I don't see why they'd loose that support when they make the LLVM backend an optional dependency?
And as Andrew writes in the proposal, this way might provide a path for better support for more obscure architectures. I would happily work on a backend for Zig for some interesting processor architecture. No way I will ever contribute to LLVM. Working with C++ in not something I'll ever do to fun
LLVM just works well on the front that clang uses, after that, llvm itself is a wild beast full of worms, which is becoming more and more painful to work with if you are a language creator/mantainer, A lot of untested paths, and hidden bugs that zig has hit before... many times.
It will NOT reimplement everything, if you read the proposal, it's in favour of changing the LLVM dependency (the libs) not dropping LLVM IR generation, this will come with performance regression since now will be up to the team to get the correct IR, and making decisions LLVM IR generation does already in LLVM
The problem is that clang is being dropped, which means, unless we have a new C++ front made in zig (a-la AroCC for C) we are gonna suffer quite a bit for projects using C++ with zig.
Writing a C++ compiler is several order of magnitude more complicated than writing a C, Java, Go or Zig compiler. There's a very good reason there are only 3 in existence despite how ubiquitous C++ is (and even then, it takes years for them to keep up with the latest standards). C++'s grammar is type 0, there's isn't even an EBNF definition of it because it's pratically impossible to write a complete one. Clang only succeeded thanks to massive investments from the biggest players in the industry, and GCC/MSVC simply grew alongside the language. All other C++ compilers died a horrible death a long time ago.
Out of curiosity, does Intel's icc compiler see much use? It looks like it uses LLVM these days, but its frontend presumably still needs to handle all of C++'s complexity.
ICC is deprecated and will no longer see a release, but it uses the EDG front-end. Its replacement, ICX (the oneAPI compiler), uses clang as its front-end.
There are essentially only four extant C++ front-end implementations: GCC, Clang, MSVC, and EDG. All other C++ compilers are based on one of these four implementations, or have since gone extinct. (Except maybe Green Hills, but I can't recall anymore if their front-end is still in-house.)
Got it, thanks! I knew that Intel had a compiler for C and C++ from reading blogs about compiler research, but I didn't know any details about its current architecture.
One of the mantras for Andrew Kelly has been "do not use Zig in production" until it hits 1.0.
People know that, but it's difficult to avoid using it for real things once you've tried it and it works :D.
I haven't done that with Zig, but with Kotlin things like serialization/coroutines/kotest/KAPT (it was the same feeling: oh this stuff is "Experimental" but so cool, I can't do real Kotlin without them!!)... well yeah, I spent many hours rewriting stuff due to that, and totally acknowledge that was on me.
Just wanted to point out that this is just a proposal, so if enough people voice their opinion, which many have already done, I am sure the core team will adjust their approach.
