OP does advocate for support by Rust Foundation and possibly inclusion into standard Rust distribution: that would change adoption by default.
Whether that's really what a community wants is a different topic. Python ecosystem and its stdlib history is a good way to look at it (eg. urllib vs requests etc).
What would be better is to have a set of standard traits that libraries can implement to provide a service.
Effectively, create a standard and let other people build things that adhere to that standard.
This gives the freedom to people to choose what implementation best suits their purpose, but still be able to write code that’s decoupled from a specific library in case it disappears.
Another standard library would just be like boost in C++. That sort of makes sense if you have no package manager so integrating new libraries is a nightmare, and type-safety is pretty lax, but Rust is on the opposite side of both of those things.
From personal experience I would copy the Go approach and do both.
Go has a large and extensive stdlib which can do basically anything.
On top nearly everything has an interface defined by that lib, which is used by third party libraries too.
So a lot of code, libraries and so on becomes sort of plug and play and just works together.
That is really great and one of the reasons why i made our company use Go for our backed stuff.
A bad standard library like PHP or a non existent like Javascripts is a thing that is a massive hindrance to developers. It wastes so incredibly much time it is absolutely insane. Ask me how I know...
The Rust people are in the unique situation that they could actually kill the fragmentation and set a standard. It's a lot if work but there are good examples to copy ideas from.
How can Rust claim to be secure if you can't do even the smallest task without importing a bunch of random crates?
This has been suggested and tried over the years, even with the same name: https://crates.io/crates/stdx
In practice, they don’t gain adoption. The current situation is just better, or at least, many more people seem to think that in practice.
OP does advocate for support by Rust Foundation and possibly inclusion into standard Rust distribution: that would change adoption by default.
Whether that's really what a community wants is a different topic. Python ecosystem and its stdlib history is a good way to look at it (eg. urllib vs requests etc).
No. This is lazy, and ignores how Rust is unique.
What would be better is to have a set of standard traits that libraries can implement to provide a service.
Effectively, create a standard and let other people build things that adhere to that standard.
This gives the freedom to people to choose what implementation best suits their purpose, but still be able to write code that’s decoupled from a specific library in case it disappears.
Another standard library would just be like boost in C++. That sort of makes sense if you have no package manager so integrating new libraries is a nightmare, and type-safety is pretty lax, but Rust is on the opposite side of both of those things.
From personal experience I would copy the Go approach and do both.
Go has a large and extensive stdlib which can do basically anything.
On top nearly everything has an interface defined by that lib, which is used by third party libraries too.
So a lot of code, libraries and so on becomes sort of plug and play and just works together.
That is really great and one of the reasons why i made our company use Go for our backed stuff.
A bad standard library like PHP or a non existent like Javascripts is a thing that is a massive hindrance to developers. It wastes so incredibly much time it is absolutely insane. Ask me how I know...
The Rust people are in the unique situation that they could actually kill the fragmentation and set a standard. It's a lot if work but there are good examples to copy ideas from.
This doesn’t solve the supply chain security issue mentioned.
Even better would be to have some of the basics in the standard library, like Go and Zig.
Time! You forgot about time API. The hardest thing in the world, to setup meeting with a person in Asia on the day before they switch to a DST