[frmdstryr]

So I spent ~4 years writing all my embedded projects (and libraries) in Zig and now several "tier 1" supported arches are just going to be dropped?

It's your language so do whatever you want but please adjust the branding accordingly...

[audunw]

Are they being dropped?

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

[frmdstryr]

"In the near term it would also reduce the number of targets Zig supports", I hope not but it sure sounds like it.

[MuffinFlavored]

They're dropping LLVM by re-implementing everything it does in their own homegrown fashion?...

To what benefit? Isn't this a waste of resources?

[delphLonepaw]

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.

[qalmakka]

> unless we have a new C++ front made in 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.

[DylanSp]

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.

[tyg13]

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.)

[DylanSp]

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.

[gpderetta]

> unless we have a new C++ front made in zig

that seems a monumental undertaking.

[brucethemoose2]

The reasoning seems to be the flood of LLVM bugs, but I don't think reinventing such a large wheel will be any easier.

[prpl]

It sounds like some of those bugs are just related to people using distro compilers?

[harerazer]

I mean, it’s no secret that zig is pre 1.0. I’m not sure this is on them, although it does seem like a drastic proposal.

[brabel]

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.

[TUSF]

This is only still at the proposal stage. The Github issue is mostly for posting usecases for and against, etc… It's not "Accepted".

[janpolak]

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.