(edit: downvotes? I'm sorry to ruin the romanticizing, but surely it should come as no surprise that these old compilers aren't fast due to black magic)
Most days I could be happy with 1 second builds.
Considering that I don’t have a million lines of code, I think 100,000 lines of code a second should cover it.
C++ is slow to compile due to some historical decisions like preprocessor.
But the C++ standard committee has come to rely on optimizing compilers with powerful inliners and optimizers, to implement new "zero cost" [sic] abstractions as convoluted template libraries with lot of corner cases (neglecting incomprehensible error messages and debug build performance as well).
Efficiently compiling C++ effectively __requires__ a top notch optimizer because of the disconnect between standards committee and implementers. Moreover, relying on optimizers often results in non obvious performance traps.
The stupidity of standards committee and their sheer insistence on nothing but being able to sell more books every years is why even modern C++ is such a horrible development experience.
Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. C++20 is nicer than '17, which is nicer than '14, which is nicer than '11, which is much nicer than '03, which is a little nicer than '98. '23 will be nicer than all of them.
The "everything implemented as library" pattern so pervasive in new C++ releases is not doing any good to the language. All those are half-baked implementation of what exists as a simple orthogonal language feature in languages like OCaml. The "implement as library" sentiment has gone too far that it hurts, among other things: * Debug build performance * Compilation times (a big thing) * Quality of error messages * Reliance on not-so-reliable optimizations, often causing performance regressions (there are many instances of this happening).
Even if clang / gcc developers are involved, probably they don't bother about 1000::template shittery because their compilers have already got comparable quality inliners, and it is hard for a competition to surface here. Or they might bother but can't be sufficiently involved into the C++ standard committee crowd.
> Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence.
And don't tell me my knowledge of last standard is obsolete and I have to read the new shiny c++ book to learn Modern C++. Another consequence is the scarcity of freely available resources accessible to students, due to rapid change.
Most people learning the newer features of C++ do not turn first to books, but rely on cppreference.com, blog posts, and on conference videos easily found on youtube.
The best way to learn the new features is to use them.
It would be lovely to have a more modern language with C++'s capabilities, but no such language is even approaching the horizon. Rust aspires to such a role, but more people pick up C++ each week than have ever coded one line of Rust. Adoption, judging from conference attendance and youtube viewership, is today growing faster than ever.
You may imagine C++ stagnating, but only by abandoning reality. Essentially all of the highest-paid development for the most demanding applications is today done in C++. For reasons.
There are only two kinds of language: those people complain about, and those no one uses. C++ is complained about more than any except Java or Javascript.
You can't actually fix it, you can only make it worse.
Simple point: Adding optimizations doesn't speed C++ compilers up faster than having do those optimizations slows them down.
Solution, stop using C++ for anything.
The most hopeful thing in the last 5 years is the move to remove C++ from new languages tool chains. Good because C++ is hopelessly broken.
Well that's an obvious point.
> Solution, stop using C++ for anything.
We can't, realistically.
I know rust is great in many aspects. I know lot of software in C++ can be written better even in an AOT'd GC language with equal or better performance, because of so many C++ performance pitfalls that appear at scale.
But we can't throw away all the code already written. There is lot of talent pool for C++. And the supposedly better languages have non existent talent pool. (Go doesn't count, such a boilerplate language hampers any readability at scale).
Before final release to QA, we can run the compiler over night on the CI and get a hyper-optimized build.
Or not, since it is a compiled language it will likely be fast enough anyway.