Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cull your dependencies

tomrenner.com

Post reply on HN
Print view View original

121–130 of 132 posts

Re: Cull your dependencies

#121

Post by ratww »

woojoo666 wrote: post #118
wcedmisten wrote: post #4

It would be nice if there were a way to quantify the value of your dependencies. If you have a dependency with 1,000 LoC and your application is utilizing 800 of them, that seems like a good reason to use the dependency. You're (hopefully) getting unit tests, documentation, and public exposure of the code (bugfix opportunities) for "free" If you have a dependency with 1,000,000 LoC and you only need 1,000, that indic…

It's not a way of detecting it but what about dead code elimination, like Javascript's tree shaking [1]? Of course if your dependency is a spaghetti, tree shaking wouldn't do much but neither would an analysis tool. Poorly architected code with no separation of concerns, will cause every entrypoint to touch every LOC [1]: https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaki...

Tree shaking could help, but an issue is that in bigger libraries there will often be shared abstractions that wouldn't be present in a more targeted implementation. Even libraries that are well architected and have good separation of concerns.

Unless the library is a collection of independent functions like lodash, there will be some interdependency (in the name of code quality!).

Of course, (ab)using "more targeted implementations" can cause other problems, like using too many libraries for example. No silver bullet.

Re: Cull your dependencies

#122

Post by netr0ute »

klardotsh wrote: post #105
netr0ute wrote: post #49

Earlier quoted context omitted.

Why make it so difficult? Just make your project AGPL and stop worrying about other OSS license compatibility.

Because AGPL implies many things not all developers want associated with their project? Yes, due to their virality, GPL-flavored licenses tend to be the "top type" that you can just cast the top-level project to and call it a day, but try convincing your corporate boss to AGPL your money-making product. That's gonna go about as well as is predictable.

Then that's not the company you want to work for.

Re: Cull your dependencies

#123

Post by jjav »

nemothekid wrote: post #119
jjav wrote: post #107

Earlier quoted context omitted.

> The corollary to "Minimize code ruthlessly" is "Roll your own X". Sure Heartbleed was bad, but are you going to write your own TLS library? But using "don't roll your own crypto" doesn't generalize to using every possible library to avoid writing any code. Down that path lies the madness of leftpad. Crypto and security protocol implementations are exceptionally difficult to write in a way that avoids all exploits,…

My counter-point is twofold. Everyone understand not to roll your own crypto not because developers intrinsically know crypto is hard but because of sustained marketing by cryptographers. It's an easy counter to point to when people swing too far into NIH. Following that I think a lot of people don't realize when they are in over their heads; it happens a lot in software estimation. It's easy to look at something lik…

> At the same time, there's a lot of hubris that goes into the statement "Every third-party library you add is an additional source of bugs, unmaged surprises", but somehow the code you write was typed by God himself.

You (everyone) should't allow hubris to drive these decisions, instead make an objective evaluation.

If you're going in saying "I can write this same functionality better than anyone else so I'll just do it", stop and rethink.

Every line of code (to an approximation) adds more potential bugs. So if you pull in a library with a million lines of code, you've added that level of magnitude for possibly future bugs. If you actually need most of those million lines because you use all the features, then you need them. In that case it would be hubris to assume that you can write the same but slightly different million lines and do much better. You can't.

But as other subthreads here point out, often you really use like a thousand lines out of that million line library. If that's you use case, you can reduce your attack surface by 999000 lines of code by writing a few functions of your own, customized to your needs without any unused frills. You don't need a god in your staff, just someone who values the reliability and security that simplicity brings.

> unmanaged surprises

To unpack this statement, I meant that when using a third party library you are now subject to their schedule and roadmap over which you don't have any say or ability to manage it. They might drop a feature you need, or break APIs in a minor release, etc. This is undeniably true, so must be taken into account when doing a risk analysis on depending on some library. Well-run libraries offer a stable platform but tons of libraries are not well-run from a release engineering aspect. Choose carefully and know what you're getting into.

Re: Cull your dependencies

#124

Post by bayesian_horse »

thephyber wrote: post #116
bayesian_horse wrote: post #64

Earlier quoted context omitted.

Reinventing the wheel is also decidedly unfulfilling.

“Fulfillment” in a developer’s programming tasks is not a valuable work product. Choosing whether to reinvent the wheel or not is ultimately a business decision that too many developers internalize. If your product team and management team are blindsided by tech debt or liabilities that you add to the code base because you decided to quietly roll your own crypto (or any other OWASP vulnerability), you are substitutin…

Companies who make their developers do stuff they feel is pointless will not see all that much "valuable work product" either.

Re: Cull your dependencies

#125

Post by ape4 »

matt_heimer wrote: post #94
ape4 wrote: post #16

Is there a minimal replacement for log4j?

The built-in JUL package seems to be what you'd want if you are trying get rid of dependencies. In practice I find that using slf4j as your logging API is a good practice. You can start with it configured to be a wrapper around JUL and then add a different logging implementation if you need more features like file rotation, etc.

How to use it in case anyone is interested...

https://examples.javacodegeeks.com/core-java/util/logging/ja...

Re: Cull your dependencies

#126

Post by mbrodersen »

lamontcg wrote: post #93

Beginner developers constantly reinvent the wheel Intermediate developers use frameworks and code that already exists to avoid reinventing the wheel. Expert developers use thin frameworks and minimize the external dependencies they need and maintain an internal library of simple foundational methods.

Nope. Beginner developers copy-paste code they don’t understand from Google searches. Including 1000+ transitive dependencies they also don’t understand. Experienced developers are really careful adding dependencies. Only adding dependencies when the value/cost equation really makes it worth it. Most Open Source dependencies are badly maintained and a bug fix might take years or will never happen.

Re: Cull your dependencies

#127

Post by mbrodersen »

Experienced smart developers are really careful adding dependencies to a project. Spending time evaluating the value/cost equation. Beginner developers copy-paste code they don’t understand from Google searches and add 10000+ transitive dependencies they also don’t know without even thinking about it. They haven’t yet been badly burned from too many dependencies not being maintained, bugs not being fixed and updates breaking your code.

Re: Cull your dependencies

#128

Post by fellellor »

nemothekid wrote: post #91
cvccvroomvroom wrote: post #76

Earlier quoted context omitted.

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

The corollary to "Minimize code ruthlessly" is "Roll your own X". Sure Heartbleed was bad, but are you going to write your own TLS library? IMO, the OP post has an unfounded sense of hubris. Everyone else's code is bad except for me, who only writes minimal code with no exploits.

The intended way to look at this is, “When I write code, I know what I wrote and the processes in my team (should) ensure other teammates know it as well”.

Re: Cull your dependencies

#129

Post by patrick451 »

bertr4nd wrote: post #85
cvccvroomvroom wrote: post #76

Earlier quoted context omitted.

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

But what’s the back pressure to this advice? If I need to multiply matrices should I write my own to avoid including MKL BLAS? What’s the heuristic that determines when a dependency is worthwhile?

As usual, it depends. A naive matrix multiplication function is pretty simple. If that's all you need and can do with sub-optimal performance, I'd write my own.

Re: Cull your dependencies

#130

Post by cvccvroomvroom »

nemothekid wrote: post #91
cvccvroomvroom wrote: post #76

Earlier quoted context omitted.

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

The corollary to "Minimize code ruthlessly" is "Roll your own X". Sure Heartbleed was bad, but are you going to write your own TLS library? IMO, the OP post has an unfounded sense of hubris. Everyone else's code is bad except for me, who only writes minimal code with no exploits.

Yes, of course. Unless you absolutely have known working pristine code free of side-channels for SHA3, ChaCha20-Poly1305, etc. don't even think about it.

The same goes for parsing and other complicated operations containing pitfalls.

Honestly, I hope most crypto, parsing, numerics libs, and OS kernels and drivetd were rewritten in Rust and given C, C++, etc. interfaces.

Post reply on HN