The problem with C++ is not _just_ a bad standard library, but it's also that. There's a lot of "don't use this", including iostreams, std::regex, std::unordered_map, std::variant, and more. Not to mention vestigial parts of failed designs, like std::initializer_list.
Every serious C++ project worth its salt includes additional dependencies to patch it up, and it looks like that will be the case in perpetuity, because these problems are unfixable in the holy name of ABI stability.
Don't get me wrong, ABI stability is a worthy goal. The committee should just have realized that the current approach to it is untenable. The result is a very half-baked situation where ABI stability is not technically guaranteed, but nothing can be fixed because of it.
What a mess.
Rust takes a much, much more cautious approach (because of C++'s history), including explicitly not supporting Rust-native ABI stability and flat out discouraging dynamic linking. Also not very great, but it's sensible as long as there are no clearly superior solutions.
> The problem with C++ is not _just_ a bad standard library, but it's also that. There's a lot of "don't use this", including iostreams, std::regex, std::unordered_map, std::variant, and more. Not to mention vestigial parts of failed designs, like std::initializer_list.
Those are the result of a constant stream of people complaining that the C++ standard library is bad because it doesn't contain their pet feature.
Needing additional dependencies beyond the standard library is not problem but how things should work. Because requirements differ and one persons useful dependency is another persons vestigial bloat.
You’re not wrong in principle, but I think it is absolutely fair to expect a standard library to include a good hash map implementation. These aren’t unreasonable demands.
The problem here isn’t that it’s bloated (I don’t particularly think it is), but that the things it provides are often very far from best in class.
The stdlib's unordered_map could certainly have been designed better but there have also been significant developments in hash map implementations since it was added so no matter what they would have specified it would be obsolete by now. Meanwhile adding your favorite hash map to your C++ project doesn't take long at all. The only issue is if you want to pass a hash map between different libraries - there a standard type would be useful. But that also requires a stable implementation that doesn't change which gets the same ossification of sub-par implementations that you already have in the stdlib.
The larger point here is that the ossification is a direct result of the combination of two things: the way that monomorphization works, and wanting to maintain ABI stability in perpetuity.
I don't know how to solve it, but it's clear that C++'s general utility is severely hampered by this ABI stability crutch.
Every serious C++ project worth its salt includes additional dependencies to patch it up, and it looks like that will be the case in perpetuity, because these problems are unfixable in the holy name of ABI stability.
Don't get me wrong, ABI stability is a worthy goal. The committee should just have realized that the current approach to it is untenable. The result is a very half-baked situation where ABI stability is not technically guaranteed, but nothing can be fixed because of it.
What a mess.
Rust takes a much, much more cautious approach (because of C++'s history), including explicitly not supporting Rust-native ABI stability and flat out discouraging dynamic linking. Also not very great, but it's sensible as long as there are no clearly superior solutions.