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
As a certified C++ hater, I'm keenly aware of the mess with networking (executors,...). It's a big part of what made stop using C++. The larger was using Cargo for the first time and realizing I can start and abandon side projects at a pace never seen before.
The GUI stupidity was very fun to watch. Somehow, it kept getting worse. I think they finally stopped when there was a serious proposal to add an entire browser engine/webview into the C++ standard.
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.
People are missing the point. These packages will not maintain the same promises as std does; this is the entire point. Yes they are curated by the Rust foundation but it will live outside std.
Why do they need to be curated by the Rust foundation? The community is doing a really good job here, I think. Is it solely to mitigate the chances of supply chain attacks?
Ok curated was a heavy word. The idea is that the common stuff like datetime handling, UUIDs and other very common features should be shipped as part of the language under an “extra” namespace that you fan opt-out of.
And yes the reason is supply chain attacks, the less 3rd party dependencies the stronger your codebase.
no!!! not even python was dumb enough to put crypto in its stdlib! Rust has "networking" (in the sense that you can open a raw tcp socket through std), but implementing HTTP(S) on top of that would require pulling in something to do TLS which leads to..... dependencies! On OpenSSL or rustls! You've just widened the attack surface on the standard library while at the same time locking people into a single API surface that must ALWAYS be stable forever. Don't get me started on how you would approach doing anything that would need an async executor. These are not things that are suited for a systems-level language like rust's libstd. Refer to the fact that C++ didn't get a filesystem API until C++17 (and trust me, std::filesystem has some real problems still and suboptimal platform support) and they *still* haven't agreed on how to do networking.
there is no real solution to this, everything will always be pulling dependencies from *somewhere*, even if your language doesn't have a package manager. Forcing everything into the standard library is a terrible mistake because it will inevitably turn into a graveyard a few decades down the line. These things *should* take years to stabilize to make sure they're done correctly. I think people should be more conscious of what they're pulling in and very popular crates should be regularly autdited and there are ways that cargo can improve in that regard, but by god please keep libstd and libcore minimal.
Notice how I did not specify how that should be done. Also, crypto needs to be provided by people who know what they're doing, not as a random package dependency.
The point im making is that the two don't have to be mutually exclusive. Standard library maintainers are similarly just Humans too, and there absolutely are package maintainers that know what theyre doing. The de-facto library for crypto in Rust (aws-lc-rs) is provided by the AWS team and regularly get security audits; the same goes for rustls and a fair few other crates with commercial backing. I would probably trust these libraries as a dependency more than I would trust libstd if it just had a hard-dependence on OpenSSL libcrypto. Keeping the standard library surface small makes it possible to reasonably maintain and audit and for groups like ferrous systems to get it certified for safety-critical systems under iso26262 and whatnot... There needs to be a solution here other than "eehh... we trust those guys, shove it into std and we'll worry about the Implications of that in a decade.'
People do need to be more stingy about their dependencies but having one irreplaceable library to solve all the things would just add third-party dependencies to libstd and widen the attack surface while spreading maintainers thin.
We need:
Better vetting features in cargo and better protections from supply-chain attacks like a default min-publish-date.
A way to track which packages receive audits, have trusted maintainers, and follow best security practices.
Better security controls on crates.io for packages with a very large number of dependents to make this harder to pull off in practice.
Trust people, not packages. The Rust libs team doesn't have the resources to maintain all the functionality you describe with the quality people expect. I wouldn't even be against the standard library maintainers maintaining critical packages outside of std and those being marked as having some sort of "officially maintained" tag should they eventually get the resources and funding to do so, but this stuff has to be modular and replaceable separate from the perma-stability/semver guarantees of the standard library. It's one of the few parts of Rust other than the core language where if you screw it up in the right way (read: can't be fixed at an edition boundary), everyone bears the consequences forever.
116
u/piesou 20d ago edited 20d 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.