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...

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.

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 :)

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.

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.

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.

Package dependency is not a binary state.

Striving to reduce the number of dependencies is a good goal.

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.

> 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.

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).

> 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?

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?".)

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?

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

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/

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

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.

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.

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.

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

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?

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.

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.