[bpatrianakos]

I disagree. I can relate to application setup and deployment feeling like its a fragile, error prone process but library usage in general is a good thing. Now if you're picking up obscure, poorly maintained libraries from GitHub I can see that going south quickly but as long as you're smart about not only which dependencies to choose from whom but also knowing when you really need them then you end up with a robust, easy to maintain system in the end.

The whole point of having a dependency chain is to benefit from well tested code that often does mundane things that you neither have the time or expertise to create yourself. I've found that as long as I choose libraries that are up to date, look to be maintained, are decently tested, and do something that I couldn't do as well or don't have the time to implement as well then all is well. I also have a rule that if a dependency is at all mission critical or not easily replaced I will either fork that library and maintain my own copy or create one for myself.

This has been true for every language I've worked with. Go, PHP, Node, or Ruby so far.

Updating might be cumbersome but if you're following best practices then you've got tests that ensure updating a library won't break your code. You also don't go around mass updating things. You update when there's a good reason to (security patches, language compatibility, etc.). Deployment should only suck the first time. Nowadays we have tools to ensure systems are replicable so you can be confident code will run fine regardless of the environment.

I don't think we'll ever have a plug and play experience. We have so many hobbyist libraries precisely because our languages and tools are so flexible. Hiding complexity is what programmers do for users. To hide from developers too would likely do more harm than good and result in a generation of programmers who don't understand how their systems really work. I point to Rails and Meteor as examples. There are Rails developers who are a thing in and of themselves. They're not Ruby devs who know Rails, they're just Rails developers. There needs to be the person like the Rails core team who know how to put dependencies together in a way that creates a functional modular system.

[bluetomcat]

A perfectly valid case for using a library is when it implements a huge standard that you don't have the time, knowledge or expertise to implement yourself. Think of zlib, libpng or libcurl. These are de facto "reference implementations" of the respective standards, so you'd better rely on them in order to be future proof.

> We have so many hobbyist libraries precisely because our languages and tools are so flexible.

I beg to differ. The (initially) small hobbyist libraries are often working around the deficiencies of the language/runtime/core libraries. This has been the case for JavaScript since jQuery. If a third-party library doesn't implement a format or a protocol, or an intricate algorithm, but rather tries to augment the language, that is a huge red flag.