5 ms·

Hi, I would like to know what's wrong with a lot of dependencies? One disadvantage I know is long compile time and maybe a little larger binary size, but I don'

Hi, I would like to know what's wrong with a lot of dependencies? One disadvantage I know is long compile time and maybe a little larger binary size, but I don't think it's too bad.

heinrichhartman 5y ago
With every dependency, you are allowing a 3rd party to inject code into your project. This can end badly e.g. #leftpad - https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/ https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how...
- samhw 5y ago
  You're doing that by running the guy's project in the first place, even if it had no dependencies whatever. I'm tired of this being brought up like it's specific to some NPM package or some guy's Rust project. Sorry, but running code you didn't write yourself is a fact of life to whose risk you will have to reconcile yourself, if you want to benefit from an extraordinary patrimony of code that no one person could write in a million years.
  - hu3 5y ago
    Package dependency is not a binary state. Striving to reduce the number of dependencies is a good goal.
    - samhw 5y ago
      Reducing the risk of malicious code is a good goal, yes. Reducing the number of all - including transitive - dependencies may be a fair way to do that. It really depends on the context of the system you're developing: is it running on users' machines, is it a critical part of the system, can it access important data, etc etc. It's certainly good to think about how to reduce supply chain risk - and that may begin with thinking about dependencies, but it certainly shouldn't end there.
      - hu3 5y ago
        > It's certainly good to think about how to reduce supply chain risk - and that may begin with thinking about dependencies, but it certainly shouldn't end there. I don't think anyone here said it does.
        samhw 5y ago
        I was responding to "striving to reduce the number of dependencies is a good goal". I don't think that's categorically true. I think it's an XY problem where one would do better to focus on the 'X' (i.e. reducing risk of malicious third-party code).
  - guhidalg 5y ago
    I agree with you, you're not wrong, but the people who use this argument are not arguing pragmatically. I believe this the "no dependency" argument is used by folks who want to virtue signal that they are "real programmers" because they don't use dependencies (ignore the kernel and all the drivers in it!!!) and instead use 100% stand-alone "free" software. Just know that you're very much not alone :)
    - samhw 5y ago
      Yeah, I'm sorry you're being downvoted. I totally agree and I'll sign myself up for getting downvoted too. There's nothing I hate more than cargo-cult programming and cargo-cult thinking, which always takes the form of these unthinking quarter-correct maxims like "dependencies are bad!", or "state in your server is bad!", or "O(1) algorithms are better than O(n) - so use my algorithm that achieves constant time by iterating over everything in the known universe!". It's not just not thinking pragmatically, it's not thinking tout court. It's a thought-terminating cliché. It's trying to reduce problem X to universal solution Y because you don't trust yourself to genuinely think it through. It's the programming equivalent of Reddit neckbeards who regurgitate (semi-accurate) names of logical fallacies from Wikipedia rather than actually evaluating the other person's argument.
    - johnny22 4y ago
      I'd say that's a huge part, which is why i dismiss most, but not all of their arguments. I think the supply chain concerns is real and important though.
  - jsiepkes 5y ago
    > You're doing that by running the guy's project in the first place, even if it had no dependencies whatever Running a naive "cargo tree" on this project tells me I'm now also trusting about 80 other projects besides this persons project. Including a Wayland client? And a "Scoped Thread Local Storage" implementation? For a sysctl replacement?
    - samhw 5y ago
      And a lot more than that! You'll be trusting: a load of silently-linked dylibs; some guy called Linus; some thing called GCC or LLVM (gosh, you don't get that with C); some weird packages called libc and crt0 and shit like that - and much much more besides. It's almost as if "a sysctl replacement?!?" is necessarily built on an extremely complex edifice of code, due to how modern computers work, which can be hidden (cf: dynamic linking) but not avoided. ;) (Less facetiously: Yes, if you start thinking through, from first principles, all the machine code which has to run in order for this tool to function on an acceptable range of computers, you can then start to grapple with the real problem, which is unfortunately more complex than "how many Rust crates does `cargo tree` output?".)
      - jsiepkes 4y ago
        Sure, it's a problem that needs to be solved on all layers. So why shouldn't application programmers take their part of the responsibility? Is that how it works? Other people also have problems, so I don't need to solve mine?
  - jjav 4y ago
    As the parent post said, "With every dependency". In other words, there is a quantitative risk difference between depending on two external libraries (particularly if you pick well-vetted ones) vs. depending on 15000 libraries like some node projects. Every additional library your build brings in, adds a small additional amount of supply chain risk. So it's not about trying to be hardline about not depending on anything, but if you want to minimize risk you'd want to curate carefully which libraries you bring in.
  - deleted 4y ago
    [deleted]
- varajelle 5y ago
  I don't think you can compare the rust dependencies and #leftpad. Crates.io don't allow to remove packages. Also dependencies don't tend to be 10 lines of code only
Deukhoofd 5y ago
Every dependency is a potential point of failure, and a security risk. It requires you to trust every dependency entirely. This could be problematic for tools like this, that run very high permission operations.
- throwaway894345 5y ago
  The code you write may equally be a security risk. Consider the proverbs which caution against rolling your own crypto, for an extreme example. Consider also the potential security issues with rolling your own OAuth or similar. Moreover, there are probably lots of other bugs to be avoided by taking on dependencies—consider the fraught domain of text rendering as an extreme example. These are competing concerns which must be weighed carefully. Trite advice like “minimize dependencies” is just as bad as “don’t rewrite it yourself”. I don’t think there are any easy answers here.
dharmab 5y ago
This is a fair question that does not deserve downvotes. Here is a recent LWN article that covers the concerns with Rust crates from an OS dev perspective: https://lwn.net/SubscriberLink/889924/321ac8bdd1fee9d9/ https://lwn.net/SubscriberLink/889924/321ac8bdd1fee9d9/
- sayanarijit 5y ago
  Thanks for the link. It was a great read and insight into the opinions of kernel devs.
gspr 5y ago
> Hi, I would like to know what's wrong with a lot of dependencies? I'm not saying that there's necessarily anything wrong with a lot of dependencies. It can be, but that's a separate discussion. What I'm saying is that it's wrong to pretend that you don't have a lot of dependencies when you actually do.
- sayanarijit 5y ago
  Ah I think there was miscommunication due to mental biases. Like I misunderstood your objection, you probably misunderstood the docs. I don't think the author is pretending anything. The docs says that it depends on procfs to highlight it as the main dependency or maybe the odd one. In Rust community, it's a common knowledge that 1. If it's a high level tool, it will have multiple dependencies, and 2. The actual dependency list will be auto generated by the package managers (cargo or os) and be pinned in every release, available publicly.
chaxor 5y ago
Security risks, faster deprecation, and less flexibility. If another dependency changes it's api, you immediately have a problem. Your answer may be to fix the version to a static value abd forget about it - but if a security vulnerability is found in that dependency afterward, what do you do? You probably won't even catch it.
- varajelle 5y ago
  The alternative is to write the feature yourself. Probably not better from a security point of view. And you have to maintain it yourself.
jandrese 5y ago
Because you need to audit every dependency along with your code when looking for defects. A huge list of dependencies, especially ones that include their own dependencies, makes this an overwhelming task. It also sucks bigtime when you're trying to install on non-internet connected machines.

Hi, I would like to know what's wrong with a lot of dependencies? One disadvantage I know is long compile time and maybe a little larger binary size, but I don't think it's too bad.

heinrichhartman 5y ago

With every dependency, you are allowing a 3rd party to inject code into your project. This can end badly e.g. #leftpad - https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/ https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how...

samhw 5y ago
You're doing that by running the guy's project in the first place, even if it had no dependencies whatever. I'm tired of this being brought up like it's specific to some NPM package or some guy's Rust project. Sorry, but running code you didn't write yourself is a fact of life to whose risk you will have to reconcile yourself, if you want to benefit from an extraordinary patrimony of code that no one person could write in a million years.
- hu3 5y ago
  Package dependency is not a binary state. Striving to reduce the number of dependencies is a good goal.
  - samhw 5y ago
    Reducing the risk of malicious code is a good goal, yes. Reducing the number of all - including transitive - dependencies may be a fair way to do that. It really depends on the context of the system you're developing: is it running on users' machines, is it a critical part of the system, can it access important data, etc etc. It's certainly good to think about how to reduce supply chain risk - and that may begin with thinking about dependencies, but it certainly shouldn't end there.
    - hu3 5y ago
      > It's certainly good to think about how to reduce supply chain risk - and that may begin with thinking about dependencies, but it certainly shouldn't end there. I don't think anyone here said it does.
      - samhw 5y ago
        I was responding to "striving to reduce the number of dependencies is a good goal". I don't think that's categorically true. I think it's an XY problem where one would do better to focus on the 'X' (i.e. reducing risk of malicious third-party code).
- guhidalg 5y ago
  I agree with you, you're not wrong, but the people who use this argument are not arguing pragmatically. I believe this the "no dependency" argument is used by folks who want to virtue signal that they are "real programmers" because they don't use dependencies (ignore the kernel and all the drivers in it!!!) and instead use 100% stand-alone "free" software. Just know that you're very much not alone :)
  - samhw 5y ago
    Yeah, I'm sorry you're being downvoted. I totally agree and I'll sign myself up for getting downvoted too. There's nothing I hate more than cargo-cult programming and cargo-cult thinking, which always takes the form of these unthinking quarter-correct maxims like "dependencies are bad!", or "state in your server is bad!", or "O(1) algorithms are better than O(n) - so use my algorithm that achieves constant time by iterating over everything in the known universe!". It's not just not thinking pragmatically, it's not thinking tout court. It's a thought-terminating cliché. It's trying to reduce problem X to universal solution Y because you don't trust yourself to genuinely think it through. It's the programming equivalent of Reddit neckbeards who regurgitate (semi-accurate) names of logical fallacies from Wikipedia rather than actually evaluating the other person's argument.
  - johnny22 4y ago
    I'd say that's a huge part, which is why i dismiss most, but not all of their arguments. I think the supply chain concerns is real and important though.
- jsiepkes 5y ago
  > You're doing that by running the guy's project in the first place, even if it had no dependencies whatever Running a naive "cargo tree" on this project tells me I'm now also trusting about 80 other projects besides this persons project. Including a Wayland client? And a "Scoped Thread Local Storage" implementation? For a sysctl replacement?
  - samhw 5y ago
    And a lot more than that! You'll be trusting: a load of silently-linked dylibs; some guy called Linus; some thing called GCC or LLVM (gosh, you don't get that with C); some weird packages called libc and crt0 and shit like that - and much much more besides. It's almost as if "a sysctl replacement?!?" is necessarily built on an extremely complex edifice of code, due to how modern computers work, which can be hidden (cf: dynamic linking) but not avoided. ;) (Less facetiously: Yes, if you start thinking through, from first principles, all the machine code which has to run in order for this tool to function on an acceptable range of computers, you can then start to grapple with the real problem, which is unfortunately more complex than "how many Rust crates does `cargo tree` output?".)
    - jsiepkes 4y ago
      Sure, it's a problem that needs to be solved on all layers. So why shouldn't application programmers take their part of the responsibility? Is that how it works? Other people also have problems, so I don't need to solve mine?
- jjav 4y ago
  As the parent post said, "With every dependency". In other words, there is a quantitative risk difference between depending on two external libraries (particularly if you pick well-vetted ones) vs. depending on 15000 libraries like some node projects. Every additional library your build brings in, adds a small additional amount of supply chain risk. So it's not about trying to be hardline about not depending on anything, but if you want to minimize risk you'd want to curate carefully which libraries you bring in.
- deleted 4y ago
  [deleted]
varajelle 5y ago
I don't think you can compare the rust dependencies and #leftpad. Crates.io don't allow to remove packages. Also dependencies don't tend to be 10 lines of code only

Deukhoofd 5y ago

Every dependency is a potential point of failure, and a security risk. It requires you to trust every dependency entirely. This could be problematic for tools like this, that run very high permission operations.

throwaway894345 5y ago
The code you write may equally be a security risk. Consider the proverbs which caution against rolling your own crypto, for an extreme example. Consider also the potential security issues with rolling your own OAuth or similar. Moreover, there are probably lots of other bugs to be avoided by taking on dependencies—consider the fraught domain of text rendering as an extreme example. These are competing concerns which must be weighed carefully. Trite advice like “minimize dependencies” is just as bad as “don’t rewrite it yourself”. I don’t think there are any easy answers here.

dharmab 5y ago

This is a fair question that does not deserve downvotes. Here is a recent LWN article that covers the concerns with Rust crates from an OS dev perspective: https://lwn.net/SubscriberLink/889924/321ac8bdd1fee9d9/ https://lwn.net/SubscriberLink/889924/321ac8bdd1fee9d9/

sayanarijit 5y ago
Thanks for the link. It was a great read and insight into the opinions of kernel devs.

gspr 5y ago

> Hi, I would like to know what's wrong with a lot of dependencies? I'm not saying that there's necessarily anything wrong with a lot of dependencies. It can be, but that's a separate discussion. What I'm saying is that it's wrong to pretend that you don't have a lot of dependencies when you actually do.

sayanarijit 5y ago
Ah I think there was miscommunication due to mental biases. Like I misunderstood your objection, you probably misunderstood the docs. I don't think the author is pretending anything. The docs says that it depends on procfs to highlight it as the main dependency or maybe the odd one. In Rust community, it's a common knowledge that 1. If it's a high level tool, it will have multiple dependencies, and 2. The actual dependency list will be auto generated by the package managers (cargo or os) and be pinned in every release, available publicly.

chaxor 5y ago

Security risks, faster deprecation, and less flexibility. If another dependency changes it's api, you immediately have a problem. Your answer may be to fix the version to a static value abd forget about it - but if a security vulnerability is found in that dependency afterward, what do you do? You probably won't even catch it.

varajelle 5y ago
The alternative is to write the feature yourself. Probably not better from a security point of view. And you have to maintain it yourself.

jandrese 5y ago

Because you need to audit every dependency along with your code when looking for defects. A huge list of dependencies, especially ones that include their own dependencies, makes this an overwhelming task. It also sucks bigtime when you're trying to install on non-internet connected machines.