13 ms·

Sorry for picking this particular project to air my gripes – it's no worse than others. But here's something that's been annoying me a lot with Rust projects (a

• sayanarijit 5y ago
  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 :)
        • 5y ago
    • 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.
• codetrotter 5y ago
  > The culture of pretending that only non-Rust deps are deps is incredibly annoying and unproductive. The reason that projects usually only list the non-Rust deps in their readme is because these need to be installed manually by the user in order to build or run the piece of software in question. There would be no point in listing all direct and indirect crates that a project depends on in the readme, since that list is already in Cargo.lock anyway which is meant to also be committed. Really don’t see any reason for this particular objection.
  • gspr 5y ago
    > The reason that projects usually only list the non-Rust deps in their readme is because these need to be installed manually by the user in order to build or run the piece of software in question. I understand that. It's almost spelled out in my comment. But the ones that can be automatically installed by Cargo are still dependencies. > There would be no point in listing all direct and indirect crates that a project depends on in the readme, since that list is already in Cargo.lock anyway which is meant to also be committed. I know. But this should at the very least be acknowledged. > Really don’t see any reason for this particular objection. It's entirely reasonable for someone not to want tooling to automatically grab dependencies from the internet. Such people need to know which dependencies they need to provide.
    • zaarn 5y ago
      >Such people need to know which dependencies they need to provide. Cargo.lock specifies exactly which dependencies are required and in which version (down to git commit hashes and checksums). You can parse that file, way less error prone that doing it by hand (you can probably even fully automate the process of checking out the dependency repos).
      • orlp 5y ago
        https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
• orangepurple 5y ago
  Do you audit the HUGE source code of the most vulnerable application you use, your web browser? It's a huge moving target with insane complexity. Didn't think so. Do you audit the source code of the compilers used to build all the software you have installed? https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... Instead of avoiding dependencies, dependencies should be locked for a release cycle and audited with automated tools to instill confidence.
  • gspr 5y ago
    > Do you audit the HUGE source code of the most vulnerable application you use, your web browser? It's a huge moving target with insane complexity. Didn't think so. No, I do not. Relevance? > Do you audit the source code of the compilers used to build your CPU? No, I do not. Relevance? > Instead of avoiding dependencies, I never said anything about "avoiding dependencies". Are you in the wrong discussion? > dependencies should be locked for a release cycle and audited with automated tools to instill confidence. Personal preference, open to debate.
  • throwaway894345 5y ago
    The parent’s grievance isn’t that projects have dependencies, but rather that projects advertise only the dependencies which Cargo doesn’t manage, which can cause confusion (the project maintainer wants to communicate that these are the only externally-managed dependencies, but at least some readers interpret this as a comprehensive list of dependencies). I’m only clarifying, not arguing in favor of the parent’s perspective.
• deleted 5y ago
  [deleted]
• ______-_-______ 5y ago
  > It's a critique of pretending that only some dependencies are dependencies. Where exactly does this project pretend that some dependencies are not dependencies? I don't see anything like that in the blog post or the readme. In the readme I see some dependencies metioned, but it's not introduced as "here are all the dependencies", it's introduced under Requirements as "here are the commands you must run to set up your system". If you open your distro package manager and look at the dependencies for an end-user app, it will not list header-only libraries. That's the same principle at work.
  • zajio1am 5y ago
    > If you open your distro package manager and look at the dependencies for an end-user app, it will not list header-only libraries Well, it will list them in build dependencies (e.g. build-depends in Debian).
• masklinn 5y ago
  > The software lists a very small set of dependencies, [...] It's a critique of pretending that only some dependencies are dependencies. But the project doesn't do that? It lists requirements and "runtime dependencies", aka stuff that you have to set up by hand. You're the only person asserting this is an exhaustive list of dependencies, with no evidence in support, and against all visible evidence.
• jandrese 5y ago
  The weird thing about needing a lot of dependencies is that sysctl is a pretty simple application. It's just a list of variables you read out of the kernel. It doesn't seem like the program that manages it should be terribly complex. Granted, this program does the manpage lookup for each variable so that adds some complexity, but that could be pre-compiled into a standardized data format pretty easily.
• pornel 5y ago
  1. Number of dependencies alone doesn't mean much, especially that Rust's dependencies tend to be much smaller than typical C deps (Cargo's ease of use and zero overhead of static linking encourages fine-grained modularity while hassle and overhead of C shared libraries encourages big libraries). So saying there are more dependencies in Rust/Cargo is like complaining that a pizza has been cut into 12 slices instead of 4 slices, regardless of the size of the pizza. 2. Cargo makes all transitive dependencies very visible (including build-time dependencies), while other solutions don't. That doesn't mean other dependencies don't have their own dependencies: https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies
• sophacles 5y ago
  I see from your edit that your complaint is: A piece of software that includes source from a different project at build time, but which does not need those other projects present at run-time due to the language compiling those dependencies into target binary, does not list the build-time dependencies as part of it's run-time dependencies? Did i get that right? If so, I think that's ridiculous. How come you're not opening tickets on the docker or k8s or repos for the exact same behavior: there's quite a few 3rd party build dependencies that are not listed as system dependencies to install it! What about the fact that those don't list `make` or `go` package dependencies to build nor as system dependencies to use the software?
• atoav 5y ago
  Usually this is an issue of your dependecies having dependecies having dependecies having... It is turtles all the way down. In your cargo.toml you have like 5 dependecies, but each of those has 10 that you don't really have on the radar etc. For really wide spread dependecies like serde I think this is okay. There are many eyeballs on it and the chances that you introduce dangerous code might be bigger if you write your own parser.