3 ms·

I've seen that happening, but there is always a risk of the old “gorilla holding the banana”[1] problem. That is, the library that you use depends on a library

I've seen that happening, but there is always a risk of the old “gorilla holding the banana”[1] problem. That is, the library that you use depends on a library you don't really need, which in turn depends on another one, etc. Once you had reached gopkg.in/yaml.v2, you've already lost. [1] https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/ https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/

weberc2 7y ago
This isn’t meaningfully true. The monkey holding the banana is an example of standard practice OO design. The standard practice for developing a suite of libraries in Go (or indeed in any non-OO language) is to decouple them. They can still work together as a suite of tools, but they can also be used independently. Not sure if this is the best example, but I would routinely use gorilla/mux on its own.