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

Kill Your Dependencies

mikeperham.com

Post reply on HN
Print view View original

151–160 of 229 posts

Re: Kill Your Dependencies

#151

Post by fixermark »

Incidentally, though the author says this can apply to any ecosystem, finding it applies to Ruby too often is what pushed me out of developing Rails apps. At least at the time I was using it heavily, the Rails space just wasn't stable enough to trust that I wouldn't have to learn an entirely new wheel to get my work done every time I went in to fix a relatively small problem.

"Can I implement the required minimial functionality myself? Own it" is advice one gives if one can't trust the libraries one depends upon to stay healthy, performant, and applicable to your use-case. Nobody'd recommend re-implementing readline or printf; if you have some heavy-lifting mathematics to do in Python, use numpy.

Re: Kill Your Dependencies

#152

Post by fixermark »

nostrademons wrote: post #106
mwcampbell wrote: post #50

A large number of dependencies is only a problem in environments that aren't amenable to per-function static linking or tree-shaking. These include dynamically typed languages like Python, Ruby, and JavaScript (except when using the Google Closure Compiler in advanced mode), but also platforms like the JVM and .NET when reflection is allowed. Where static linking or tree-shaking is feasible, the run-time impact of br…

Not always. Dependencies were a huge problem at Google, even in C++ (perhaps especially in C++), because they mean that the linker has to do a lot of extra work. And unlike compiling, linking can't be parallelized, since it has to produce one binary. At one point the webserver for Google Search grew big enough that the linker started running out of RAM on build machines, and then we had a big problem. There's still n…

That's a pretty significant special case though. I'd be willing to go with the advice "If you get as big as Google's codebase, be sure to trim the dependencies on your statically-bound languages too." But you probably have a ways to go before that's an engineering concern for your project.

(... note that one could make a similar argument for more runtime-dynamic languages. I won't disagree, other than to observe that as a lone engineer, I've managed to code myself into a corner with dependencies in Rails ;) ).

Re: Kill Your Dependencies

#153

Post by fixermark »

diggan wrote: post #2

As everything, I think a bit of balance is needed. You're doing a quick MVP to demonstrate that your idea is working? Fuck it, just throw in dependencies for everything, just care about solving the problem you're trying to solve and proving/disproving your point. Once you verified it, then go and kill your dependencies. But don't do it just because you want to do it. If in the end the users doesn't benefit from you o…

s/kill/understand, which is useful advice for software engineering in general.

As time approaches infinity, the number of magic "I use this package and it does something in my code, and then it all just works" dependencies you pull in should approach 0.

Re: Kill Your Dependencies

#154

Post by fixermark »

riffraff wrote: post #103
simonw wrote: post #7

Another benefit to minimizing your dependencies is security. The less external packages you are using (especially packages without active, security-conscious maintainers) the less likely you are to suffer a surprise vulnerability due to something deep down in your dependency hierarchy. This goes for client-side JavaScript too. XSS holes are one of the worst web app vulnerabilities out there and could easily be introd…

but otoh, if you try to reinvent something instead of using a tried & true library, you might as well just add new bugs. I.e. I'd 100% use libxml to sanitize xml rather than trying and reimplementing xml parsing myself. As always, trade offs.

Yep.

OpenSSL has major security issues encountered on a relatively regular basis.

Do not do your users the disservice of rolling your own SSL implementation. ;)

Re: Kill Your Dependencies

#155

Post by ktRolster »

skewart wrote: post #79
ktRolster wrote: post #37

Earlier quoted context omitted.

As an architect, you need to be able to do a cost/benefit analysis of each option. That is what software architects do, why they have experience. For example: How much time will it take to implement each option? How much time will it take in the future to support it? What security risk does each option incur? What is the risk of the project being abandoned? What is the risk of the project changing in non-backwards co…

One thing I've gotten into the habit of doing is looking around the commit history and issue list for any package I import. Was it something somebody wrote in a hurry and hasn't really touched since? Is it something that has a solid set of regular contributors? Are there a lot of outstanding issues relative to how heavily used it is? I also spend more time actually reading through specs to see how well they exercise…

That's a good idea

Re: Kill Your Dependencies

#156

Post by kibwen »

LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

This reminds me of Objectivist-C:

http://fdiv.net/2012/04/01/objectivist-c

"In Objectivist-C, software engineers have eliminated the need for object-oriented principles like Dependency Inversion, Acyclic Dependencies, and Stable Dependencies. Instead, they strictly adhere to one simple principle: No Dependencies."

Re: Kill Your Dependencies

#157

Post by AndyMcConachie »

LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

There's always going to be a balance between reusing code someone else has wrote, and writing new code. They both have their pros and cons.

Re: Kill Your Dependencies

#158

Post by ctstover »

nostrademons wrote: post #106
mwcampbell wrote: post #50

A large number of dependencies is only a problem in environments that aren't amenable to per-function static linking or tree-shaking. These include dynamically typed languages like Python, Ruby, and JavaScript (except when using the Google Closure Compiler in advanced mode), but also platforms like the JVM and .NET when reflection is allowed. Where static linking or tree-shaking is feasible, the run-time impact of br…

Not always. Dependencies were a huge problem at Google, even in C++ (perhaps especially in C++), because they mean that the linker has to do a lot of extra work. And unlike compiling, linking can't be parallelized, since it has to produce one binary. At one point the webserver for Google Search grew big enough that the linker started running out of RAM on build machines, and then we had a big problem. There's still n…

Ran out of RAM or address space? I've run out of RAM trying to ridiculous stuff like native builds on tiny embedded systems (due to whack code bases that wouldn't cross compile). Though, in the end I overcame this with even more perverse solutions like adding swap space via USB1 flash.

That aside, that is the third time in a couple of months that I have heard people mention situations where they ran out of RAM without explaining why swap could not at least work as a stop gap measure.

Re: Kill Your Dependencies

#159

Post by nostrademons »

ctstover wrote: post #158
nostrademons wrote: post #106

Earlier quoted context omitted.

Not always. Dependencies were a huge problem at Google, even in C++ (perhaps especially in C++), because they mean that the linker has to do a lot of extra work. And unlike compiling, linking can't be parallelized, since it has to produce one binary. At one point the webserver for Google Search grew big enough that the linker started running out of RAM on build machines, and then we had a big problem. There's still n…

Ran out of RAM or address space? I've run out of RAM trying to ridiculous stuff like native builds on tiny embedded systems (due to whack code bases that wouldn't cross compile). Though, in the end I overcame this with even more perverse solutions like adding swap space via USB1 flash. That aside, that is the third time in a couple of months that I have heard people mention situations where they ran out of RAM withou…

Ran out of RAM for cloud builds - Google generally does not use virtual memory for anything in the cloud, because it leads to unpredictable, massive delays which can cause cascading failures in services.

It was still "possible" to build on your workstation, but the locality patterns in linking and subsequent thrashing made this extremely an extremely small value of "possible". I recall once during this period I kicked off a local debug build on my workstation on Friday afternoon, went home for the weekend, and it was still running when I got into work on Monday morning. By Tuesday, I had given up and killed it.

Re: Kill Your Dependencies

#160

Post by thibauts »

gglitch wrote: post #138
LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

Charming quote. The same argument could be made about making your own food "from scratch." But it's not a solid refutation of the essay. Let's say that if one end of the spectrum is unlimited dependencies and complete indifference to the complexity and size of the project, and the other end of the spectrum is raising your own goats, there must be an ideal somewhere in the middle.

As a middle-ground, one could leverage existing source and send patches to fix the inefficiencies.
Post reply on HN