It's not possible to do with crates.io because of the culture it has.
When I pull in GLib, APR, libuv, etc as a dependency, that is literally the only dependency. They depend on glibc, maybe libpthread/libm, and nothing else.
I'm being a bit unfair to tokio, since they seem to actually be trying really hard to keep their dependencies down.
But I'll stick to my belief, as that seems more unusual than usual to me, for crates.io libraries in general. C has a culture of minimalism. Rust has a culture of easy of use. The latter is a nightmare for trust.
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++.
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.
When I pull in GLib, APR, libuv, etc as a dependency, that is literally the only dependency. They depend on glibc, maybe libpthread/libm, and nothing else.
When I pull in tokio, I now have 40 dependencies.