[eternalban]

OP doesn't ask the question that would have saved a somewhat straw-man general position on frameworks: Why is it that Go lacks the familiar 'widely adopted framework'?

OP could have written about the two different types of code reuse and why one lends itself better to Go: Libraries vs Frameworks.

Java has magical frameworks because we have a magical JVM and first class (as in baked into the language) metadata utilities at the language level. Java can define & load new objects at runtime. Loose coupling? My god, this is as loose as it gets. In Go, you'll need composition of processes to accomplish the same thing.

Code reuse at Go happens at the library and networked-but-loosely-coupled component levels. This covers a lot of territory but not things that are, in effect, 'containers of components'. If you are in component oriented code sharing territory, Go is the wrong language. With Go, a framework can't do all the magical stuff the other kids' FWs do, but you get most of the pain of using frameworks. It is a language issue.

in general: Partially realized abstractions place greater demands on the language and its runtime capabilities than do partially realized composition (e.g. apis).