upvote

points

by aDyslecticCrow104 days ago |
comments
upvoteby kibwen104 days ago|
next
[-]
But Rust doesn't have an abundance of small/atomic libraries. This is describing NPM, not crates.io. Rust doesn't have the same culture as Node.
reply
upvoteby eqvinox103 days ago|
parent|
next
[-]
There might be fewer small crates, but I've still seen massive dependency lists. Case in point: tokio. How many "related" crates do you deal with for various features? 5? 50? It's not great.
reply
upvoteby aDyslecticCrow103 days ago|
parent|
prev|
next
[-]
It's a range, but rust is closer to Node than it is to c and c++ in this culture.

I would probably place rust in-between python and node. It is made worse by the relative in-maturity of the ecosystem which contributes to the fragmentation. Rust will likley improve, but I have little faith for Node, as it's cultural as you mention.

Case in point; here is a list of most used crates. Some of these contain a single macro or wrapper. https://lib.rs/std

reply
upvoteby pjmlp103 days ago|
parent|
prev|
[-]
Say what?

Any Rust project has endless crates scrolling up the screen.

It has exactly the same culture as npm, which is no wonder, because many folks adopting Rust come from Web background, not C and C++.

reply
upvoteby kibwen103 days ago|
parent|
[-]
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.
reply
upvoteby pjmlp103 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-...

reply
upvoteby woodruffw103 days ago|
parent|
next
[-]
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.)

reply
upvoteby int_19h100 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).

reply
upvoteby normie3000104 days ago|
prev|
[-]
I haven't seen this perspective before but it's a very elegant explanation for why e.g. npm is so much scarier than maven.

I wonder if safety could be improved a little if private package management was easier than throwing things out in public.

reply
upvoteby Veserv104 days ago|
parent|
[-]
Newer languages have made packaging and importing dependencys significantly easier, but have done this while increasing coupling and making switching dependencys harder. This results in brittle dependency trees.

Using a private package manager, intermixing private and public, and substituting arbitrary dependencys with compatible alternatives, i.e. modularity, should be easy. Only then does solving the problem become easy.

What we used to have is a big ball of mud. Modern languages made it easier to decompose a system into components. But what we really want is easily decomposing a system into modular components which is yet unsolved.

reply
upvoteby int_19h100 days ago|
parent|
[-]
> What we used to have is a big ball of mud. Modern languages made it easier to decompose a system into components. But what we really want is easily decomposing a system into modular components which is yet unsolved.

We need to take modularity a lot more seriously, and by this I don't mean just making things more pluggable, but also well-defined component boundaries and contracts on them.

Sadly a lot of this stuff is moving at a glacial pace, and little of it is mainstream. Design-by-contract was introduced 40 years ago, and yet no mainstream PL in use offers anything past the bare minimum (asserts). Niche tech like Ada SPARK is picking it up, but even there it took decades.

And now we throw AI into the mix and expect things to work. Madness.

reply