undefined

points

[-]

No, this is mistaken. A crate is both rustc's unit of compilation and Cargo's unit of dependency. Feel free to lament this conflation all you like, but what it means is that the common pattern is for library authors to publish large crates that are internally split into smaller crates for better compilation parallelism. This just isn't a problem by any metric; it doesn't increase your trusted computing base. That's not at all the same problem as NPM has with its web of frivolous micro-dependencies.

by pjmlp104 days ago|

parent|

[-]

It is surely a problem given the cumulative time everyone waits compiling them distributed across Rust users.

Also if it wasn't a problem, articles like this wouldn't exist,

https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...

by woodruffw104 days ago|

parent|

[-]

This is backwards: per GP, the cumulative time would be greater if there were fewer crates, because of how incremental and parallel compilation work in Rust.

(This doesn’t mean Rust doesn’t have a dependency proliferation issue, only that the way you’re substantiating it is misleading: it’s like saying that C has a dependency proliferation issue because libfoo goes from having 3 source files to 5 source files between releases.)

by int_19h101 days ago|

parent|

prev|

[-]

If the same code was all aggregated in a single large crate, it would still be compiled as a single unit, so I don't see how it would affect compilation times. And, of course, that is orthogonal to security issues.

That pip/npm/cargo model doesn't play well with distro package managers is not a new thing. I think that eventually the distro packagers will have to bite the bullet and just start packaging apps that need any of these as bundles (which, yes, means that they need to be serviced separately for security updates; but there's no reason why the metadata used to decide when that is necessary should be the same as install-time package dependency graph).