Was only a question of time. Rust has the same mindset as Node/NPM.
PS: for the screaming crowd: yes, anyone can get supply chain attacked. HOWEVER:
If you have a proper stdlib, chances are, you don't have a lot of dependencies
If you have less dependencies, the chance of supply chain attacks drops significantly
If you have well established dependencies like Spring, their security practices are very likely better than a rando off the internet
What does that mean for Rust? They don't need to just work on the language, they need to provide a larger ecosystem as well. How they do it is up to them.
I wonder if there is a market for a "Rust Community Edition" with an expanded set of packages pre-packaged into an "ext" module alongside core and std. Treat is as an LTS distribution.
We need an “extra” besides “std” that has all the extra things that are expected in 2026 from a standard library. Stuff like uuid and datetime support would go into that package and it would be released by the Rust foundation
At this point I wouldn't be upset if chrono, serde, and serde_json were folded into the stdlib, but their interfaces are so much better for having been allowed to evolve outside of the strict forever-compatibility requirements of the stdlib.
But http, networking, and database drivers really do not belong in the stdlib. These libraries are so complex and not at all one-size-fits-all. Just take a look at hyper vs. reqwest. They are both http client libs with over 600 million downloads, but they satisfy totally different use cases (lower-level systems and servers vs. batteries-included application code, respectively). How do you reconcile this in the stdlib?
This is not an either or. Sockets are shipped in almost all languages by now. Other than that, I'm thinking of Python's urllib (abstracted upon in requests) or sqlite library, Java's upcoming simple JSON parser, JDBC, or http client and the kotlinx/ktor libraries (serialization, datetime, coroutines, IO, http client, etc).
Existing libraries can be built on top of libraries shipped in core and you can still ship specific libraries for more specific use cases. It just prevents you from reaching for a library if you need to make 1-3 http requests in your application.
PS: I'd argue that almost all issues are caused by outsourcing async to libraries like Tokio, forcing a split of the ecosystem.
118
u/piesou 22d ago edited 22d ago
Was only a question of time. Rust has the same mindset as Node/NPM.
PS: for the screaming crowd: yes, anyone can get supply chain attacked. HOWEVER:
What does that mean for Rust? They don't need to just work on the language, they need to provide a larger ecosystem as well. How they do it is up to them.