Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries.
I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.
Which is how you get the mess that is the standard library of C++. Where regex is an unusably slow joke and everyone uses third party libraries for that instead.
And tons of parts of the standard library (and language) being cordoned off as "legacy, don't use for new development". Of course figuring out what you shouldn't use in C++ can be hard too. It isn't well documented (or universally agreed upon), and it takes having it as a full time job to be able to keep up with these days.
Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.
Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.
which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)
We also have the classic example of PHP with numerous not safe stdlib ways to use mysql.
To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.
Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc).
No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.
Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries.
I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.
Which is how you get the mess that is the standard library of C++. Where regex is an unusably slow joke and everyone uses third party libraries for that instead.
And tons of parts of the standard library (and language) being cordoned off as "legacy, don't use for new development". Of course figuring out what you shouldn't use in C++ can be hard too. It isn't well documented (or universally agreed upon), and it takes having it as a full time job to be able to keep up with these days.
No, I much prefer the way Rust is doing it.
Add more and more to a standard library, and you're going to start losing your "works everywhere".
Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.
Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.
Just because some trees have a specific trait, it doesn't mean the whole forest is the same.
which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)
Those aren't the only two choices.
We also have the classic example of PHP with numerous not safe stdlib ways to use mysql.
To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.
> We also have the classic example of PHP with numerous not safe stdlib ways to use mysql.
I think it goes without saying that emulating PHP is rarely a good decision.
Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc).
No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.
Which isn't actually a problem. You can ignore the bad standard library and use something different.