Comment by vsgherzi
2 months ago
Supply chain incidents suck and we need to do better. Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.
Crates has also been making efforts to include rust sec, but in addition to the above I would like the community to shy away from many small dependencies to a few larger ones just as tokio has
Many small crates published by large, trustworthy projects are fine and preferable to one large crate that "does everything".
Why?
Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java. Are benefits in binary size really worth that complexity?
And before someone says “just have a better standard library”, think about why that is considered a solution here. Languages with a large and capable standard library remain more secure than the supply-chain fiascos on NPM because they have a) very large communities reviewing and participating in changes and b) have extremely regulated and careful release processes. Those things aren’t likely to be possible in most small community libraries.
8 replies →
Yeah I’d agree that multiple crates under one project is basically the same as 1 large crate. The real problem is how many people you’re trusting and it’s all coming from the same person.
Contrary to what the article here presents, Rust does not have a culture of microlibraries like NPM does. The author and their LLM are cargo-culting a criticism of Rust made by people whose only experience is with the Node ecosystem. The Rust stdlib may not be especially "wide" compared to languages like Python, but it is quite deep, with the objective of making it so that you don't feel the need to publish single-purpose libraries which only exist to fix papercuts. Dozens of new APIs get added with every Rust release, which, occurring every six weeks, amounts to hundreds per year.
What are you talking about? Every Rust project I see seems to have 5 dependencies that do some simple thing that should be in the standard library, or at least in some centrally-audited monolibrary of utilities.
4 replies →
Move high value crates into the standard library?
Indeed, I'm all for maximizing the amount of modules in the standard library. It's pretty obvious to me that Python thrives because of, not despite of, its standard library, "dead batteries" and all.
However, don't make the mistake of thinking that Rust has a small standard library. Read any Rust release and you'll see dozens of new APIs added with every single one. I'm tempted to paste the entire list of stabilized APIs from the most recent release for emphasis, but rather than making this comment three dozen lines longer, just look for yourself: https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/#stabilize...
In particular, most recently the aforementioned release stabilized the cfg_select! macro for convenient conditional compilation, which obviates the popular cfg_if crate: https://doc.rust-lang.org/stable/std/macro.cfg_select.html
An extra tier of standard library which can make breaking changes, perhaps. Rust's stability guarantee for std means cryptography really shouldn't go in there, since sometimes algorithms & protocols get broken (DES, MD5, SHA1, etc.) and need to be removable. Without breaking changes you get stuck with security vulnerabilities, if not from cryptography then from other poorly-designed APIs.
Maybe give crates a gold star if they have no external dependencies?
That's not at all a bad idea, imo. And a silver star for crates which only depend on gold star crates...
It's hard to have zero deps - I put many hours into one to have no required deps in the end but it was not easy, and writing declarative macros to do anything complex takes work (and a proc macro often means a minimum of two crates). Both of the crates it requires are part of the same project, however.
One of my other crates (getaddrinfo) requires windows-sys and libc which would be challenging to get rid of.
I like the idea of low deps but zero is tough
https://crates.io/crates/ctor/1.0.4/dependencies
1 reply →
This only encourages rewriting perfectly fine libraries badly. There's no simple metric to actually optimize here.
Please no, that’s a terrible outcome.
What else would you suggest that also does not have terrible outcomes. The situation as is, is untenable.
1 reply →
This bloats the std library and forces lots more work and stress on the rust dev team. Not to mention it’ll add more churn to the std lib.
One man's bloat is another man's batteries-included, I guess?
My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild.
2 replies →
do we really need both npm and nmp though
and pnpm
You forgot pnmp! How can you not be using pnmp in 20267!?
1 reply →
A ton of the most popular crates on crates.io are already first-party crates provided by the Rust organization itself. This is often overlooked when people are wringing their hands about Rust crate graphs. Looking at the top 10 list of most-downloaded crates on the front page of crates.io, the only one not either from the Rust organization or from a Rust core maintainer is the base64 crate.
honestly I thought this was the end goal of blessed.rs
nah, remove NPM, nothing good comes out of that.
[dead]