[vsgherzi]

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.

[vsgherzi]

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

[fleventynine]

Many small crates published by large, trustworthy projects are fine and preferable to one large crate that "does everything".

[zbentley]

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.

[pornel]

Why? It's the essence of "Simple Made Easy": you don't have other code to complect with. You have a smaller interface, focused on a singular goal. When a library has to work as a standalone project, it can't be accidentally entangled with other components of a larger project.

Smaller implementations are also easier to review against malware, because there are fewer places to hide. You don't have to guess how a component may interact with all the other parts of a large framework, because there aren't any.

There are also practical Rust-specific concerns. Fine-grained code reuse helps with compile times (a smaller component can be reused in more projects, and more crates increase build parallelism).

It makes testing easier. Rust doesn't have enough dynamic monkey-patching for mocking of objects, so testing of code buried deep in a monolith is tricky. Splitting code into small libraries surfaces interfaces that are easily testable in isolation.

It helps with semver. A semver-major upgrade of one large library that everyone uses requires everyone to upgrade the whole thing at the same time, which can stall like the Python 2-to-3 transition. Splitting a monolith into smaller components allows versioning them separately, so the stable parts stay stable, and the churning parts affect smaller subsets of users.

[mswphd]

worth clarifying the build parallelism is because the fundamental unit of compilation in rust is the crate. so the main option available to cut down the running time of a large crate is to split it into smaller crates.

[CoastalCoder]

Tangent, but thanks for adding "complect" to my vocabulary!

[lmm]

> 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.

Commons and Spring have spent significant effort to break themselves up in the past, and would probably come as aggregations of much smaller pieces if they could be started today with the benefit of hindsight.

[xg15]

You will have lots of dead code in your build.

That dead code might have "dead dependencies" - transitive dependencies of its own, that it pulls in even though they are not actually used in the parts of the crate you care about.

In the worst case, you can also have "undead code" - event handlers, hooks, background workers etc that the framework automatically registers and runs and that will do something at runtime, with all the credentials and data access of your application, but that have nothing to do with what you wanted to do. (Looking at you, Spring...)

All those things greatly increase the attack surface, I think even more than pulling in single-purpose library.

[tardedmeme]

Libraries like Guava and Commons don't have transitive dependencies - they are self contained except for other parts of the same library.

[rcxdude]

The same issue occurs whether you bundle all the code together or not, it's just that if you bundle it together you don't see what's happening and you can't use only part of it easily.

[duped]

Rust's compilation unit is a crate. Counting crates is like counting source files in C++.

> Are benefits in binary size really worth that complexity?

What complexity?

[vsgherzi]

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.

[kibwen]

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.

[MarsIronPI]

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.

[kibwen]

Perhaps you're referring to things like regex and rand (each of which is itself multiple crates for the purpose of code organization), which are all first-party crates provided by the Rust organization itself, simply shipped and versioned separately from the standard library? If you trust the Rust organization enough to install and run the provided toolchain binaries on your machine, then you trust them enough to depend upon the dozens of crates that are provided under the umbrella of the Rust project.

[ChrisSD]

Can you name 5 as an example?

[DreadY2K]

Not GP but I feel like there's a continual process of the stdlib adding some new functionality to make one such crate redundant (e.g. is-terminal in 1.70), but it isn't done yet.

[ChrisSD]

Yep, that's why I was asking. I'd be very interested to hear of more candidates for uplifting into std.

I guess saying "every project" has 5 dependencies might be somewhat hyperbolic (or at least domain specific) but it would be interesting to know the kinds of things they're talking about that haven't yet been uplifted.

[hacker_homie]

Move high value crates into the standard library?

[kibwen]

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

[SAI_Peregrinus]

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.

[hacker_homie]

Maybe give crates a gold star if they have no external dependencies?

[sdenton4]

That's not at all a bad idea, imo. And a silver star for crates which only depend on gold star crates...

[mmastrac]

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

[hacker_homie]

That’s because you are not moving thing into the standard library :)

[rcxdude]

This only encourages rewriting perfectly fine libraries badly. There's no simple metric to actually optimize here.

[orf]

Please no, that’s a terrible outcome.

[pixl97]

What else would you suggest that also does not have terrible outcomes. The situation as is, is untenable.

[vsgherzi]

As I said above

“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.”

This is my solution. We get the quality of a std lib without forcing it in the std Lib and without extra maintaining cost for the team

[vsgherzi]

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.

[jcgl]

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.

[vsgherzi]

The rust team is already stretched pretty thin. A larger library is going to put more pressure on them. These libraries are already maintained and used. The rust project should just directly, fund, Shepard and guarantee a level of quality for the packages. The foundation has started some of this with the maintainers fund. No need to force it all into the std lib. Go has experienced breaking issues with changes in the crypto library causing churn in the ecosystem.

[jcgl]

Point taken about the core team being stretched thin. But I don't see how the "increase stability of some core crates" is enough to change the packaging practices/culture. Maybe I'm wrong, but you really don't get those ecosystem benefits unless the ~entire ecosystem buys into that set of packages. Which really doesn't happen without stdlib.

Also, I think that your example of Go's breaking crypto changes misses the forest for the trees--the stdlib has been incredibly stable through its history, and the vast majority of packages just never have to worry about it. I'm honestly not aware of a language out there with similar adoption, featureset, and robustness. More to the point, I'm not aware of a language out there with a more reliable stdlib that permits the ecosystem to have small dependency graphs.

[suprfsat]

do we really need both npm and nmp though

[fragmede]

and pnpm

[MarsIronPI]

You forgot pnmp! How can you not be using pnmp in 20267!?

[rmoriz]

Just use the implementation of petty, a js runtime written in Zag that is just rewritten by AI in Rust. It will be memory safe.

[kibwen]

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.

[dijit]

honestly I thought this was the end goal of blessed.rs

[PunchyHamster]

nah, remove NPM, nothing good comes out of that.