The real problem is the latter: C++ has always had a "you don't pay for what you don't use" as part of its core philosophy but it turns out that doesn't apply if the thing you don't use is ABI stability.

(and, failing an ABI break story, std::regex should have had an implementation that was more PIMPL and less template so it would have fewer ABI issues, possibly followed by a regex2 later that could get more of the compile time bits once implementations were more mature.)

C++'s separation of spec from implementation is clearly functional. There are several major open-source standard library implementations that compete on the basis of performance, ABI stability over versions, quality, etc.

C++'s core ethos is "only pay for what you use". std::regex does this. In my experience, the "problem" with std::regex is that it provides more features by default than most people want, and you pay for using those features. Specifically, std::regex respects the runtime locale. There are good reasons a standard library feature might do this (e.g. it simplifies the interface, it's broadly applicable, etc.), but it's obviously not going to give optimal performance. This is a necessary tradeoff for any standard library.

Locale handling requires dynamic memory allocation, virtual function dispatch, sometimes system calls. Locale handling also prevents some low-level optimizations based on the character encoding. If you need that kind of performance, std::regex probably isn't for you, go grab a non-standard library that suits your needs.

It's not too late to introduce an actual stable ABI though. However, it's not too late to do that in Rust either so I don't see the point in a language specific ABI in the future anyway.

So this is only a painful problem for people who don't use C++ very much, and whatever centralized, official solution to builds would probably not really get adopted by most C++ shops.

Because of that, even if it were solved, it's likely that it would only solve the problems that people who don't use C++ very much, or who don't invest in build tooling, want fixed. Which is basically what Make was originally.

IMO it's best to think of C++ as a language only. Because of Microsoft/Sun/the web/etc and the desire to win over developers' business, a lot of newer languages are designed to be batteries-included with official first party tools that are supposed to be the canonical way to solve that particular class of problems. Those languages are essentially products or brands that are part of their benefactors' grand designs for specific business or career outcomes.

C++ by contrast has multiple competing implementations for basically anything you can think of, and isn't someone's "business" the way most other languages are, so there's no reason to make the out-of-the-box DX better or standardize the tooling. Nobody has any reason to want you to write C++ instead of something else.

Large FAANGs that would be incentivized to change it don't care because they have their own in-house C++ build systems like bazel (Google) or buck2 (Meta) that are far faster than cmake (distributed compilation and caching) but require huge teams to maintain. Unfortunately, this distributed compilation and caching layer is something that many other languages don't have since their build systems are made for single devs building locally.

Also the dependencies can be added in a myriad of ways. Your build system can download them, your meta-build dependency manager can find them (Conan), your Linux distro can provide them (system libraries), or maybe you just download an object file from a website + some headers and are told to figure it out yourself (many commercial packages like cuda or steam).

C++ is used for large, very, very, very, very complex problems. Language-specific build systems always like to assume all the world is their language. But not all my world is C++, just 99% and that last 1% is all kinds of weird, screwy things that require a very complex build system. CMake is up to the task, in part because CMake is used for building more than C++ and so they've thought a little bit about the issues I have.

Anyone who says CMake and C++ are complex languages is utterly completely wrong. Sure, by comparison to something better designed, they're a little more complex, but we're only talking a little bit. Meanwhile, I have tens of millions of lines of code to deal with. My real complexity isn't the language, it's my code and that is far greater than all these little complaints people have about the language complexity.

I mean, it is a real problem, it is making life hard on developers for no good reason, but sometimes, artificial friction can work against some anti-patterns. Similar in spirit to "chaos engineering".