[spease]

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.

[LordHeini]

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.

[necovek]

On top of ignoring the main concern regarding supply chain issues (and I would argue this would make it worse), "fixed" interfaces might also stop or slow down any innovation there.

And tbh, most "new" libraries get developed for both a better API and improved function.

[cloudhead]

This doesn’t solve the supply chain security issue mentioned.

[spease]

Maybe, but it’s kind of half-assed to just figure out a solution that only works for stdx and then leave every other library out to hang.

Supporting tools like cargo audit would be a better choice for the entire ecosystem, not just things that are appropriate to have in stdx.

[necovek]

I am not sure you are proposing a solution for the raised problem: the more people there are in the supply chain, the higher the risk that someone turns rogue or gets hacked.

How could cargo audit help there when you don't know if a particular package has been infiltrated?