[ainar-g]

Probably mostly off-topic, but every time I see the words “Go” and “framework” together in a sentence, I can't help but chuckle. Go is, idiomatically, a very anti-framework and pro-library language. And I think that that's a good thing. The closest thing idiomatic Go has to frameworks are the stdlib's “interface packages” like package image or package database/sql/driver, which are amazing because they make it easier to create an actual ecosystem instead of a network of incompatible frameworks. Anyone who wants to create a “framework” for go should instead learn from those packages and try to define a set of interfaces which work together to achieve a goal.

[st3fan]

I think that is better explained as

"the Go _community_ is very anti-framework and pro-library"

There is nothing about the language, which is general purpose, that makes it anti-anything really.

[pgwhalen]

I would argue that the lack of features like generics and meta programming (annotations/decorators) push Go the language away from frameworks.

(I know that the absence of generics is temporary)

[st3fan]

This is nonsense. There are plenty frameworks, like the one discussed in this post. The lack of any kind of language feature has never stopped people from writing solid libraries, frameworks and applications in Go. Lots of examples out there.

[pgwhalen]

I didn’t say there aren’t frameworks, I said there is a reasonable argument that the language’s feature set tends away from frameworks.

[kerng]

I agree, especially when words like idiomatic are used it usually is very one sided perspectives. I know popular startups that use their own in house Go frameworks, and many of the devs there worked at Google, some on Go. They would use packages and make them appear like classes to other callers, etc... basically mimicking long proven design patterns in their frameworks.

Also, lots of dependency injection patterns everywhere, which is actually a great way when dealing with larger projects.

[arcticbull]

Well, the garbage collector makes it anti-embedded but otherwise I agree with you. Languages aren't "high level" or "low level" they're whatever you and the community choose to do with them. The libraries that exist help speed that along of course.

[CharlesW]

> Go is, idiomatically, a very anti-framework and pro-library language.

Can you elaborate on this? I'm not super-familiar with Go but I haven't yet seen anything that suggests it's a poor language choice for frameworks.

This also makes me curious about your definitions of "framework" and "library". Frameworks are just curated collection of libraries that work well in harmony, plus conventions for handling common patterns. No?

[ainar-g]

I mostly use the well-known distinction: with libraries, you call the library code, but with frameworks, the framework code calls you.

Frameworks are often architecture-first and functionality-second, which is vice-versa for libraries. Instead of learning to “do X” you are now learning to “do X using Y”, and that Y often prevents you from knowing and using the full potential of X.

Also, when I say that Go is idiomatically anti-framework, I mean that most idiomatic Go code I've seen, in the stdlib and in the code of the prolific gophers, tends to shun the structure of frameworks. It's in the “Zeitgeist”, if you will. In fact, in my experience most frameworks are written by people who come to Go from other languages and try to take their habits with them. A good example of that is the Martini HTTP framework, the author of which later acknowledged that he was trying to “write Go as if it were another language” and started creating stdlib-compatible middlewares instead.

[giancarlostoro]

Agreed. Go has none of the magic of say Python or C# where at first I just pretend its all magic so I can build a site but slowly I look into the underlying framework code so I can learn how it really works.

In Go all your code is explicit about what its doing. I dont know of any guru annotation witchcraft in Go outside of people doing preprocessing which is avoided by the language by design.

You can open any source in Go and usually just figure out whats what and where it comes from.

[skybrian]

The http package in the Go standard library is a framework by this definition. You define HTTP handlers and install them at certain routes. It doesn't seem bad?

But I think people are more concerned about bigger and more complicated frameworks.

[arcticbull]

> I mostly use the well-known distinction: with libraries, you call the library code, but with frameworks, the framework code calls you.

Haven't heard that before but I really like it!

[erikpukinskis]

> in my experience most frameworks are written by people who come to Go from other languages and try to take their habits with them

Same thing happened to JavaScript, and now the language is ruined, sadly. It's now a crappier, but more widely deployed Ruby.

[diehunde]

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?

[ainar-g]

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/

[weberc2]

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.

[_y5hn]

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.

[diehunde]

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.

[_y5hn]

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.

[dominotw]

what if I just want to build a quick CRUD website. Why would i want to assemble bunch of libraries, instead of using a web framework. Framework is pattern of assembly that fits a specific need, why would everyone create their own.

[alphakilo]

From my experience with micro, it is pretty easy. You can use the template commands with `micro new user` to make a service and `micro new api --type=api` to create the api. Add a data layer to the User service for persistence. Next, you can create a user service client called by the routes in the api. Then running the micro runtime via `micro api` will allow you to make calls to domain.com/api/{RPC}.

[jy3]

net/http is all you need. You don't need any library or framework.

[dominotw]

not sure if you are joking but does net/http have

1. server side templating of html pages

2. database access/migration

3. asset packing/versioning

5. css compliation/ asset pipeline

6. authetication/authorization support

[_y5hn]

While Golang could be used for that, the original target was to be a "systems language", more of a niche. There are people building websites and even games, but you won't find all the expected bells and whistles. There could even be current shortcomings in the language itself for such use cases, so you would be more "on your own" with such a solution, at the moment.

[throwaway55554]

> what if I just want to build a quick CRUD website

[dominotw]

RoR might have effected my definition of what 'quick' means :D. Things I mentioned in the comment above are indeed 'quick' in ror.

I assume you are implying these are not quick in golang ? I think it proves my point that assemble everything yourself is a silly ideology when applied generically to all things.

[pm90]

It does not.