Hacker News Reader

Comment by diehunde | Hacker News Reader

I've seen some frameworks for other languages that are actually a collection of libraries and you select the ones that you need. Isn't the same with these Go frameworks?

View on HN

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/

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.

Starting by choosing a framework is very anti-"Go Way". Instead, you could start with a minimal prototype, learn what features you're gonna need, implement themselves or find a library that can complement your code. The last resolution, would be to fetch a fully-fledged framework. You would at that point have learned from experience how to use it as a decoupled amplifier.

It's not that you can't do it, it's just that the entire ecosystem and excellent stdlib encourages you to develop your own code, and makes it very easy to refactor, catching most non-logical bugs at compile time if there are any.

Yeah but a lot of prototypes will have similar requirements. Let's say I need to build an app I already know will need to route requests, authentication, versioning, some sort of sql layer to not write SQL code, etc. I don't see a problem with starting with a framework for that. I'm new to Go so maybe all of that it's extremely easy to do without any library, in which case I would be wrong.

How do you know exactly the implementation of all that, or wether there's simpler alternatives for your chosen bounded context? It's not just a Go thing, though the language promotes using stdlib more and external dependencies less, starting small and build from there. If you were to use a particular gaming engine or web framework, sure, but then again unless you know Go to be a great fit, or built by you to be great, why use Go at that stage. How would you know beforehand?

It's not so much writing the code, that's the easy part, but reading and tweaking it later and not go hmm..

There something to smaller, simpler and btw, nobody is saying golang is currently a good fit for all kinds of projects, but the core ideas are easy for new developers and interesting for experienced ones.

Composing smaller components into a bigger system would be a great fit, and it could also be used for a monolith, though golang really shines most where code is segmented into clever little independent features. This may require some extra design and systems thinking.

Reply on news.ycombinator.com