This is not just true for Ruby but also for the entire npm ecosystem.
I wonder how much traffic could be saved by optimizing npm packages... probably on terabyte scale at github alone, methinks.
Kill Your Dependencies
11–20 of 229 posts
Re: Kill Your Dependencies
#12To me, this seems more like an argument for optimizing beyond your own stack. Don't kill your own dependencies.
Your app uses to much memory? Improve a dependency, you have now improved other peoples apps, too.
Your app uses to much dependencies in total? Try to get all your first-level dependencies to standardize on the best http-client. (Which he is partially doing with his post.)
Dependencies may have problems, but shared problems are better than problems only you have.
Re: Kill Your Dependencies
#13It sounds like this is advocating NIH syndrome. If a library is going to make my job easier I'm going to use it, unless there is a very specific benefit of doing it myself.
Re: Kill Your Dependencies
#14A lot of apps (old-timey Windows apps, for example) have this philosophy, leading them to reinvent things like crypto and image decoding. Naturally, this leads to tons of bugs, including security bugs.
I would revise this to: Don't bring in more code than you need. But if the choice is between writing something yourself and using someone else's well-tested, heavily-used library, always go for the latter.
Re: Kill Your Dependencies
#15Looks like the mime-types upgrade has some sort of hard dependency on Rails 5? I seem to be stuck on 2.99
Re: Kill Your Dependencies
#16This should be one of the perks of Go since the compiler won't let you include anything that you aren't using.
Re: Kill Your Dependencies
#17I'm not 100% sure I agree with this as stated. Sure if the functionality is in core lib, use it but... it depends... Consider these three statements: - No code runs faster than no code. - No code has fewer bugs than no code. - No code is easier to understand than no code. For a language like scala where there is no json processing in the standard lib, if there is a json library that is battle tested, then by removing…
I think the point of the article is: use external libraries thoughtfully. I don't think he was suggesting not using them at all.
Your example sounds like a situation where a dependency certainly makes sense.
Re: Kill Your Dependencies
#18Yes, this is the sort of thing that scares me away from Ruby.
I'm worried this sort of "screw it just add a library" is going to spread further in my language of choice: Java.
In my time doing open source programming on the side, I've found that it has become more common with the advent of things like mvn and gradle to just slather on layers to your stack even for the simple tasks.
Need a function to turn a byte buffer into a string? Download these 3 Apache commons libraries and their dependencies.
I understand if you are relying on a large portion of a library and you need to use it, but why bring an entire library in for one function.
Re: Kill Your Dependencies
#19Avoid shims.
There are lots of libraries that just put one interface on top of another interface. They don't do much actual work. Pulling in shims, especially if they pull in lots of other stuff you're not using, should be avoided.
If the dependency does real work you'd otherwise have to code, then use it.
Re: Kill Your Dependencies
#20A lot of apps (old-timey Windows apps, for example) have this philosophy, leading them to reinvent things like crypto and image decoding. Naturally, this leads to tons of bugs, including security bugs. I would revise this to: Don't bring in more code than you need. But if the choice is between writing something yourself and using someone else's well-tested, heavily-used library, always go for the latter.
> Don't bring in more code than you need.
I see it as a sliding scale. If I'm parsing 1 string with the same date format into 1 object, I'm not going to pull in some general purpose time parsing library - I'll write the 10 lines of code myself, a few unit tests, and be happy.
If in the future I start having to deal with different date strings and some need to do more than just throw up a single date on a page somewhere, I'll get a date/time library.