> Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin.

Why not ?

There is one open C++ spec, that's really hard to implement, so we have a dozen C++ compilers that are impossible to support properly because they each have their own set of different ten thousand bugs.

The value of supporting all of this is really small in practice, and the cost for everybody involved is huge.

Having a single, e.g., C++ parser with a single set of bugs is a much better value proposition for C++ programmers.

We did have one major C++ compiler on Windows (MSVC) and one major C++ compiler elsewhere (GCC) and they both stagnated in many areas before Clang came along and forced them to advance to stay competitive.

GCC wasn't elsewhere.

Up to 2005 I was using UNIX own C++ compilers, meaning aCC, xlC, SunPRO.

Then there were Microchip, ARM, TI,...

There are real benefits to be gained though from new compilers. Look at "Circle" by Sean Baxter as an example. Outside of supporting a powerful form of compile time computation and allowing things such as reflection and writing shaders directly in C++, benchmarks have been floating around showing that it compiles quite a bit faster than GCC and Clang whilst still being able to compile big projects such as Boost. Although LLVM is the backend, the front-end is written from scratch by one guy.

https://www.circle-lang.org/

Clang is lagging behind in C++ 20 support while MSVC is miles ahead. LLVM is also getting slower and slower every release.

So?

I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse.

I do see how it would make this much better.

What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across compilers lowers it.

You sound like you haven't worked with many BigCo projects. Clang is turning into an "enterprise" junkyard due to too many cooks spoiling the broth, crumbling so much under the weight of its own complexity that 2022 is almost here and support for C++20 still isn't anywhere near complete (unlike GCC). The more parties that get involved, the worse the code will get. Clang already has more people working on it than MSVC, yet MSVC is iterating faster; this suggests a fundamental problem with the architecture or development processes of Clang, which is not something that will be fixed by more hands on deck (remember the mythical man-month).

Many of the proprietary C++ compilers (Intel included) are just repackaging of the EDG front end. The monoculture has existed for a long time in the C++ world due to the complexity of implementing the language to spec.

Honestly, I think it will be great to have one less set of compiler-specific oddities to worry about.

MSVC does not use EDG for the frontend as far as I'm aware. IntelliSense does, though.

Not anymore, they changed that in the last few years

Funnily, the only reason I ever used ICC was as a linter since it was the most easily available EDG-based commpiler for me and different frontends help find different bugs.

> Competition is good.

On the other hand, collaboration is also good. Why waste time reinventing the wheel?

Because reinventing the wheel is how progress is made. You car isn't made with wheels from 17th century.

Who told you reinventing wheel is how progress made?

Can we be precise here? I never had a memory about a major technical progress being reinventing the wheel.

To be precise:

1. Just because there is Linux, doesn't mean everyone should jump on the Linux bandwagon and abandon all work on illumos, NT, QNX, Fuchsia etc. Focusing everyone on Linux would kill progress.

2. Just because there is x86 or RISC-V, doesn't mean noone should invent new architectures. Apple went with their own and that's what gives them their edge now.

3. Just because there is already Emacs, doesn't mean that all editors should be Emacs mods.

4. And back to compilers, just because LLVM already has optimizers, doesn't mean that other people shouldn't explore other designs for their backends. Especially that LLVM is really slow, and a major bottleneck for new compilers now (see Rust, Zig and Jai e.g.).

> illumos, NT, QNX, Fuchsia

Who told you these are reinventing the wheel of Linux?

AFAIK, NT was a consumer desktop OS turned into server and meant to serve the foundation for both consumer and server OS.

QNX was a auto operating system, for which Linux does not work.

Fuschisa is meant to be a unibersal mobile OS.

These are not the same thing as Linux.

I did not meant to label theses as reinventing wheel. If I left you with such impression that was my fault in communication.

So your car wheels are still made of wood with metal roundings?

If modern tires are considered reinventing the wooden wheels, sure, then reinventing wheel is the main form of making progress. But I doubt that's how people thinking about reinventing wheel, when they use that phrase to mock others of wasting energy inventing something that has already a very-well-working alternative.

So you would drive a chariot on the same places as a four wheel traction drive Jeep?

Sorry, I was saying that reinventing wheel does not apply to the invention of modern tires...

So why aren't we all using JOVIAL to develop IoT systems?

Apparently it wasn't required to reinvent any other high level language for embedded systems programming, it was already solved problem in 1960.

Why reinvent the wheel for embedded systems programming?

Idk about JOVIAL, but I certain mind too see some modern Ada out there.

Wasn't LLVM reinventing the wheel at the time? They could just collaborate to GCC.

They wanted to, but RMS wasn't interested at that time: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...

I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with. At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project.

> I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with.

Add another. (Now-former professional compiler developer.)

> At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project.

This is the ‘RMS loophole’ in the GPL. In theory you can do what you want with the source; in practice you need help from the insiders.

Sure, I'm not denying any problems with the GCC codebase and/or how RMS handles GNU software.

Just pointing that reinventing the wheel is not necessarily a bad thing or a waste of time.

Maybe if GCC project wasn't opposing the ability to easily integrate third-party tools we wouldn't have LLVM to begin with.

> Don't want to end up with every C/C++ compiler being a clang skin

I've wasted too much of my life dealing with compiler differences, and I certainly do want that.

Well competition is good for consumers but is not for the actual market players. And what's the point of competing in the compiler space?

> And what's the point of competing in the compiler space?

To an extent, processor vendors sell CPU's based on how they perform on SPEC{int,fpu}. So what matters is not how fast your HW is, but rather on how fast the combination of HW + compiler is.