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.

Regex does the job for most business software, iostreams is alright, using them since 1993, std::format is cool provided one has control over their compiler version,...

Regex is absolutely not suitable for most use cases that I have come across. Iostreams formatting is awful, especially if you care about internationalization (which is very common).

Not sure what the issue with std::format would be here, you would have to elaborate. Obviously you need to specify a minimum version to have support for it at all.

It works good enough for stuff I would be using Java or .NET for.

Not every application requires internationalisation, especially server code or internal company tools.

Which isn't actually a problem. You can ignore the bad standard library and use something different.

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.

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.

It's interesting that you include Java in there, as I've worked on some pretty bog-standard Java code bases where the dependency tree didn't look all that different from a cargo project's.

It starts by those that reach out for Log4J, when java.util.logging.Logger already does the job.

Guava for whatever cool reason, and so on.

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.

Your argument only works for no_std crates, but the std exists and allows the vast majority of crates to be cross platform out of the box.

I bet there are plenty of them that don't work on IBM i, while Java does fine there.

Just to quote a possible scenario among others.

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.

Regex drama is overblown, it is quite usable for most business purposes.

Sure, it would be great if the volunteers that contribute to C++ compilers, would improve regex instead of adding the gazillion of features that each ISO C++ standard requires, mostly on their free time, because devs can't be bother to pay for compilers.

Additionally the companies that actually sponsor those compilers also have bigger priorities than improving regex implementation.

Finally if you want to stick regex into a micro-benchmarks context, there are plenty of options out there, as you point out.

The Rust way, like you can have any async runtime, as long as it is Tokio?

Regex issues aren't at all overblown, at least in the fields I have worked in or in fields of people I have talked to.

As for async in Rust, I wrote in another comment that yes that is an issue. What we need is std to define traits that all the different runtimes can implement. Because there are absolutely reasons to use alternative runtimes, depending on what you do. I mostly use embassy (embedded microcontroller development) for example. And if you want thread-per-core with io-uring you want glommio or monio. Smol is simple and compact.

I could also see uses for async in desktop GUI or gamedev (but to my knowledge there isn't any runtime suitable for those domains yet).