On the other hand, there are some bad Go standard libraries that are frozen in time.
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.
Just to quote a possible scenario among others.
Guava for whatever cool reason, and so on.
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.
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?
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).
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.
I think it goes without saying that emulating PHP is rarely a good decision.
No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.
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.
Not every application requires internationalisation, especially server code or internal company tools.