Cargo being part of the language has lowered the barrier for code re-use. This is a good thing. And the reason Rust libraries seem to be more granular and numerous than C or C++ libraries which seem to conglomerate into monstrosities like Boost. Cargo allows for pinning dependencies, vendoring dependencies, and even the dependencies of dependencies.

Supply chain attacks are real threats however, which plague any language with or without a package manager (see the XZ backdoor for a great example of a supply chain attack in C). Rust projects may have many more dependencies than C projects, but that's precisely because each is smaller and easier to verify, because Cargo makes integrating many libraries easier than the process has been historically for C/C++.

> Cargo allows for pinning dependencies

If I pin dependencies, I am susceptible to not getting security updates.

> because each is smaller and easier to verify

If I do not pin dependencies, then I am susceptible to crates.io shenanigans, where the artifacts uploaded to crates.io are not necessarily the code that was verified on github.

One of the 100 owners of my mini-dependencies will bump up their minor version by 0.0.1, push a rootkit/backdoor to crates.io (which was never on github), wait for a few users to retrieve that, then push another 0.0.1 update which removes it. Nobody will notice anything.

I can't believe I'm defending Boost here (I hate it) but at least it has some basic gatekeeping; one of their maintainers will have to approve that change, one of Debian's maintainers will have to pull that change, and I know the artifact I get was built on Debian's servers from the source code that is now set in stone forever, visible to everyone.

I don't get that with crates.io. Especially when each of those 100 mini-dependency owners can directly push code straight to my PC.

> If I pin dependencies, I am susceptible to not getting security updates.

True in every language.

> If I do not pin dependencies, then I am susceptible to crates.io shenanigans

I do think it would be nice to have a chain of trust associated with crates.io. Nothing precludes doing that, as far as I know. There's probably already a cargo plugin for it.

> One of the 100 owners of my mini-dependencies will bump up their minor version by 0.0.1, push a rootkit/backdoor to crates.io

This is a situation Cargo.lock can prevent.

Thankfully crates.io is much easier to audit than millions of lines of decentralized [c/q/]make files, bash/zsh/csh scripts, etc.