40 ms·

Yes, but one cannot count transitive dependencies as if they are not your dependencies. They are still all needed to build your project, thus they are effective

Yes, but one cannot count transitive dependencies as if they are not your dependencies. They are still all needed to build your project, thus they are effectively yours as well. I find the pure number of dependencies involved worrying tbh (and this is not strictly related to your project, but if this is the case throughout the whole rust ecosystem, then it is a global problem).

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 ago
  I feel like the trend is going the other way in modern JS
  - codr7 2y ago
    God I hope so!
  - technojamin 2y ago
    I'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.
_flux 2y ago
Yes, there is trust involved in assuming that others also include useful dependencies. So far I have not seen it being brought up as a concrete example that there is a single useless dependency in the project. Seems like it should be easy to show, as between the lines there seems to be the claim that there are many. I agree that having a great number of sources needed to build your program is worrying from the point of supply chain attack, but at the same time most developers enjoy focusing on the core problem they are solving, not problems that others have already solved for them. Vendoring dependencies might be a partial solution, though practically speaking it seems locking dependencies via git hashes would be effectively the same.

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 ago
I feel like the trend is going the other way in modern JS
- codr7 2y ago
  God I hope so!
- technojamin 2y ago
  I'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.

_flux 2y ago

Yes, there is trust involved in assuming that others also include useful dependencies. So far I have not seen it being brought up as a concrete example that there is a single useless dependency in the project. Seems like it should be easy to show, as between the lines there seems to be the claim that there are many. I agree that having a great number of sources needed to build your program is worrying from the point of supply chain attack, but at the same time most developers enjoy focusing on the core problem they are solving, not problems that others have already solved for them. Vendoring dependencies might be a partial solution, though practically speaking it seems locking dependencies via git hashes would be effectively the same.