[samhw]

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.

[guhidalg]

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]

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]

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.

[jjav]

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.

[hu3]

Package dependency is not a binary state.

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

[samhw]

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]

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

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

[jsiepkes]

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

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]

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?