[pjmlp]

Only in the minds of GC haters that cannot grasp the concept of system enabled system programming languages.

Both of them wouldn't exist.

Go because it is basically Java 1.0 with AOT compilation.

Rust because C++ wouldn't have become as widespread as it currently is.

Stil trying to catch up with Xerox PARC,

http://toastytech.com/guis/cedar.html

[higerordermap]

Not to mention C/C++ literally killed compiler optimizations research. C++ committee's ignorance towards practical concerns such as debug build performance, error messages, build times and ignorance towards prior art has kept programming world 20 years behind.

[adwn]

> Not to mention C/C++ literally killed compiler optimizations research

They did what now?! I guess that famous 4-letter compilation/optimization library [1], which had its origins in academia, and which is extensively used by computer scientists as a base for their compiler optimization research, and which is written in C++, and which was originally targeted at compiling and optimizing C and C++ code, is just a figment of my imagination.

[1] It's LLVM.

[higerordermap]

You are conflating two different things. LLVM and GCC are __written__ in C++, that doesn't mean C++ is best language for optimizing i.e code written in C++ provides best opportunities for optimization.

The highest gains in optimization come not from bit twiddling transformations on integer arithmetic. They come from interprocedural analysis, especially since cache locality is so important these days. Optimizing compilers being written in X is not same as code in X being well optimizable.

C was considered slower in some cases than Fortran because aliasing information. __restrict flag in C fixed that. But C const is not transitive, and const-ness is convention rather than strictly enforced by compiler. This makes optimization hard across API / ABI boundaries. __restrict is also not transitive. If you analyse asm generated by sufficiently large program, you will sure find missed optimizations. C standard even permits any data to be accessed via a char *.

C++, while is C-speed because of direct compilation, value types and manual memory management, has too much of non-obvious performance traps in form of copy constructors, iterators etc.. std::vector can't use efficient realloc implementations, maps have to keep iterators valid, and you don't know when some copy constructor is going to be invoked and allocate memory. C++ is known as fast because its competitors in enterprise space were Java (which is often written with too many layers of indirection, has a memory hungry VM as most popular implementation and lacks value types) and unscientific [0] languages like python. Any sufficiently large C++ project that involves junior engineers will have undesired performance bottlenecks due to the idiosyncrasies of language and its ecosystem.

The massive layers of template implementations also cause performance bugs deep down, like those found in Microsoft's std::vector::insert implementation. Not to mention API practicess that encourage hidden object initialization / copying.

While I don't like the zealot instagram-ish community surrounding rust, I think the language is well designed and it has strong points in these areas. Any reference being immutable xor writeable provides ample opportunities for optimization[1]. Clone operations are explicit. And iterators are well designed. While there are small things like TrustedLen on iterators being introduced only recently, I think rust is much better optimizable than C++ is.

[1] These optimizations are held back by LLVM bug. No LLVM is not the best compiler possible as some people will make you believe. What it gets you in some more optimization passes, you lose in horrible compile times, and mediocre codebase. LLVM is mostly a proprietary-able version of GCC, while its existence has led to some good clang-based tooling in ecosystem, the monoculture is harming advances in compilers.

[adwn]

> You are conflating two different things.

No, I'm not conflating anything. Your claim was hyperbolic and completely false, and I refuted it.

> [...] that doesn't mean C++ is best language for optimizing i.e code written in C++ provides best opportunities for optimization.

You're moving the goalpost.

[higerordermap]

You didn't understand what I meant. I didn't move the goalpost. You understood what I meant only after reading that sentence.

It is hard for one to claim compiler research is affected because of most common implementation language. I don't know why you got that interpretation.

> Your claim was hyperbolic and completely false, and I refuted it.

Even GPT3 writes this after getting trained on some HN pages.

[adwn]

> I didn't move the goalpost.

Your original claim was: "C/C++ literally killed compiler optimizations research." Your updated claim is: "C++ is [not the] best language for optimizing."

[otabdeveloper4]

> ...C++ committee's ignorance towards practical concerns such as debug build performance, error messages, build times...

These practical concerns have no place in an ISO standard.

Do you even know what the C++ committee's purpose is?

[higerordermap]

> Do you know what standard committee's purpose is?

Writing and selling more books.

All these are affected by evolution of the language. As the standards committee pushes more and more multi-layer templated library features as modern best practices, debug times suffer, error messages suffer, compile times suffer.

The C++ committee doesn't look at prior art in academic literature[0], they don't even consider many implementation concerns which only become apparent after implementations are widely used in real world. The gap between language designers and implementers is obvious.

There are C++ apologists who claim it is because of legacy. Yeah but I won't be buying those books every three years until they half-fix every misfeature in half broken template library way.