It remains relevant to programming language choice because the "best in class" libraries in Rust often have lots of dependencies, thanks to Rust culture and cargo's design.
I'd like to be able to pick a few libraries without incurring a huge ongoing audit burden. If I have to exclude many popular libraries because they have oodles of dependencies, that both makes searching more laborious and limits my choices.
I still don't understand what alternative people are arguing in favor of. When I think of those "best in class" libraries like regex, serde, etc, those are multiple crates that are developed by the same teams. Having one massive crate or one hundred tiny crates is irrelevant here, because if they're all developed by the same contributors it does not increase your trusted computing base.
I do think that there's some work that can be done to improve reporting on our side: cargo should be able to report not just "how many crates are in the dep tree" but rather "how many owners am I depending on" and "how many repositories am I depending on". For example, I just noticed that there's no way to see in crates.io other crates that live in the same repository, like it does per owner, even though it has that information available.
Cargo currently has `cargo tree`, which prints out a dependency tree. There's an extension to cargo which also shows how many people have the ability to push to your dependencies, titled `cargo-supply-chain`.
There is really just a handful of crates that nearly often get pulled in and probably like 5 authors across them.
Supply chain harderning is pretty easy in rust: caro-deny, cargo-suply-chain, cargo-crev, cargo-vet, cargo-{s}bom and probably a few more I can't remember.
I'd settle for most dependencies not having any dependencies at all; at a minimum making a serious effort to only add dependencies that really pull their own weight.
This starts from explaining outright which dependencies they have and why.
It's not so much direct dependencies that bother me: it's an exponential explosion of transitive dependencies.
Also, seeing an “end product” with dozens of dependencies doesn't bother me much; a library does.
Is each web framework expected to reimplement regex, path matching and HTTP protocol logic themselves?
Should every physics/ML/etc library have to write their own array abstractions and operators? If every networking library had to write and ship their own async executor logic, I can safely posit that would be about 100x worse than it is now.
The alternative to “zero dependencies” isn’t full “JS/NPM-dumpster-fire”.
The obvious answer is "N crates is N dependencies", because each crate represents a discrete sequence of atomic software release packages.
In the absence of a standardized mechanism to group crates together, we have to fall back to informal methods, like "I know all these authors personally because I'm an insider", or "these crates seem to be related even though I'm unsure how to guarantee they'll stay that way".
You can take a hard line and insist that nobody should run a single line of code they haven't reviewed, but that severely constrains the ability of a typical org to use the wider ecosystem at all. Not every org has the expertise on staff to pore over diverse Rust code and confidently state that it has no issues, and even those that do have to consider whether paying that cost is good risk management.
It would be nice if there was a more reliable way to simplify the evaluation of publisher trust centers, especially for orgs who aren't going to audit code but don't want to blindly take in anything.
I'd like to be able to pick a few libraries without incurring a huge ongoing audit burden. If I have to exclude many popular libraries because they have oodles of dependencies, that both makes searching more laborious and limits my choices.