* Batteries-Included Standard Library - can't actually be a standard library, but could be the next best thing, a widely-used library; things like NSPR and APR for C, or Boost for C++
* Third-Party Package Repositories - Conan, which seems to be healthy, but hasn't taken over the world
* Documentation - Doxygen, which has been very successful
* Write Once, Run Most Places - little progress towards this for C, but the people in the C++ standards process do at least think about portability; i think there is an inherent tension between portability and being close to the metal which means it is always going to be a lower priority for C or C++
* Package Managers - see under 'Third-Party Package Repositories'; not clear to me to what extent this is a different thing
* Code Formatters - these have long existed, i suspect clang-format is most popular, but it is far from universal; what's missing is a universally-accepted strict formatting standard, as found in Go and Rust, and arguably now Python
So, it seems that these things do get retrofitted, and do get adopted, but not to the same extent as if they were there from the beginning of the language.
First, as the author states, it’s hard to get consensus on a tool if it wasn’t baked in from the beginning. I don’t think there will ever be a dependency manager or especially an option-free formatter for C++ with the same adoption as gofmt or go modules.
Second, it helps a lot to have the compiler/runtime authors think about the tooling. Go runtime developers think about pprof. GCC developers don’t think about the UX of valgrind. C++ standard authors don’t write PR’s for code formatting tools when they change the language spec.
I know a C++ guy who insists that C++ already has a dependency manager — he says it’s called Docker. Not sure I agree, but that’s the kind of attitude that seems to grow when a void exists; people get by with “good enough hack for my use case in a pinch”, and then over time that turns into “this is the way it’s done”.
Your friend uses Docker. My friend uses Apt (and hopes the libraries he wants are in there). Someone else compiles by hand and uses pkgconfig. Or CMake files. Or VC++ referenced projects. Or XCode projects. Or autotools. Or hand written make files. Or ninja. And so on.
Universal tooling only has value when it’s universal. Adding yet another contender to the mess doesn’t really help unless it becomes a standard.
I think the first two steps sometimes happen, but the last one is where things get stuck. Often times a better experience means incompatibility with the previous solutions, so adoption happens slowly if at all. Then eventually yet another incompatible solution comes out, and things fragment.
Yeah true, legacy code must be a factor. If most people in C++ are working in legacy code bases that don't leverage many thrid-party packages then I guess there is little desire to standardize on a third-party package manager.
Another issue is more social. C++ has lots of package managers which is almost worse than declaring Conan the standard. Communities standards are hard to retro fit I guess?
(Not to pick on C++ by the way. Every popular language eventually sees itself competing with newer incumbents. It's like the innovators dilemma for PL. )