Rust needs an extended standard library | Hacker News Reader

Rust needs an extended standard library

kerkour.com

24 pointsamatheus11 comments

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.

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

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.

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?

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.

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.

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

How can Rust claim to be secure if you can't do even the smallest task without importing a bunch of random crates?

Reply on news.ycombinator.com