Generally speaking, Go is not a good fit for frameworks (which are meta-tools by definition). Implement the actual tool itself in Go, not a framework to build the tool.
I would disagree with this - it's a very broad statement. While building frameworks often encourages developers to abstract to the nth degree and add far more flexibility than is required, if you have specific requirements what's the problem?
We built a microservice architecture in Go at Hailo which runs approx 170 services. Abstracting core functionality into a 'framework' allowed developers to build and deploy services extremely quickly, and let the platform team get on with adding and improving core platform functionality, such as monitoring, instrumentation, tracing, provisioning, configuration etc etc.
One of the things I love about Go is that I don't have to learn all kinds of conceptually heavy frameworks to get real work done. I read the stdlib docs and get to coding.
I've also found that when I'm tempted to stray from Go idioms and do something too generically, I tend to get punished by the language. So I've learned to just suck it up and do everything the "Go way". I don't consider this a negative--rather that Go is just not very tolerant of other language styles. You have to accept this.
I think the best way to describe it would be to make a distinction between frameworks and libraries. A framework integrates itself too much into the application's overall structure, while a library provides another tool that lets you write your code the way you've always been writing it, but to do something new.
The weakness of the type system becomes a problem pretty quickly - simply having a different implementation of an adaptor, be it per language, transport or even simply type of node makes for an endlessly leaking abstraction.
That's what I felt that overlapped with the GP's comments on composing complexity. It's not so much that you _can't_ implement multiple cases (not to the nth degree, just a handful), it's that the abstraction leaks painfully.
I find your and the parent's arguments really interesting.
For me Go reminds me so much of Java 1. And it seems to be getting pulled by the community in the enterprise Java direction e.g. generics, annotations, dependency injection, broad frameworks and the simple, tightly focused tooling direction.
The community isn't pulling Go into any of those things.
* Go had annotations since pretty much day 1. Look at the annotations for JSON serialization, for example.
* Generics is something that Go is probably not getting. It's just become a troll topic at this point since everything that could be said about this topic, has been said.
* Dependency injection is something that Go isn't getting. It's a Java solution for a Java problem. Create well-thought out code with clean interfaces and unit tests... problem solved.
* Broad frameworks: it's just not going to happen. As a lot of other commenters have said, Go just doesn't support the level of abstraction that you need to create a FactoryPatternPatternStrategy. And that is a good thing, in my opinion.
* Tooling: I have no idea what you mean really. Java's tooling is hardly "simple" or "tightly focused" (have you ever USED Maven?) and Go's community didn't "pull" the golang authors to create simple tools... they've been simple and focused since day one.
