3 ms·
I second that reaction to many Rust projects I've compiled. Anything JS these days tends to look similar. I think part of the issue is that it's just so easy t
by codr7 2y ago
I second that reaction to many Rust projects I've compiled.
Anything JS these days tends to look similar.
I think part of the issue is that it's just so easy to get a package included in "the" central registry, and for many programming adepts that's like a badge of honor. So you get many tiny libraries, and many turn into balls of mud. Then they learn about reuse and happily pull in all dependencies they can think of.
In Rust there seems to be a tendency to keep stuff out of the standard library, so everyone depends on their favorite solutions to everyday problems, which depends on their favorites and so on.
But it is a problem, because somewhere along the line one of those indirect dependencies is going to start conflicting with something else in the graph; the bigger the graph, the more conflicts.
And finally risk, because if a major indirect dependency goes belly up, that may well cause serious problems for your direct dependencies, which then makes it your problem. Also directly related to graph size.
- dagurp 2y agoI feel like the trend is going the other way in modern JS
- codr7 2y agoGod I hope so!
- technojamin 2y agoI've definitely seen "zero-dependency" as a selling point for several packages in the past few years, that's always very refreshing.
- giyanani 2y ago> But it is a problem, because somewhere along the line one of those indirect dependencies is going to start conflicting with something else in the graph; the bigger the graph, the more conflicts. Rust is statically compiled, so it’s possible to have different versions of the same dependency in your dependency graph without build issues. Yes, that can lead to binary bloat and slower build times and some related problems, but in practice the compiler is good at dealing with those issues.