[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.