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.
And for what it's worth cl compiles faster for me than even clang-cl. I like having both available though.
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.
Up to 2005 I was using UNIX own C++ compilers, meaning aCC, xlC, SunPRO.
Then there were Microchip, ARM, TI,...
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.
Honestly, I think it will be great to have one less set of compiler-specific oddities to worry about.
On the other hand, collaboration is also good. Why waste time reinventing the wheel?
Can we be precise here? I never had a memory about a major technical progress being reinventing the wheel.
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.).
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.
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?
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.
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.
Just pointing that reinventing the wheel is not necessarily a bad thing or a waste of time.
I've wasted too much of my life dealing with compiler differences, and I certainly do want that.
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.