In addition to the points raised in the other replies, I would observe that Go lacks most of the meta-programming features that frameworks rely upon to deliver

In addition to the points raised in the other replies, I would observe that Go lacks most of the meta-programming features that frameworks rely upon to deliver value. You can't monkey-patch, you can't annotate functions, you can't really introspect types or do typical dynamic programming stuff. You can often use package reflect to hack up something approximating a solution to this class of problems, true. But, like package unsafe, package reflect sidesteps a bunch of language assumptions, conventions, idioms, etc. which means any code that uses reflection is going to be subtle, brittle. It's a tool of last resort, really, an escape hatch. Not something that you should consider part of your tool set. This is all by design, I think. Go tries to ensure that a straight-line reading of the code accurately represents the execution flow. So you can't really implement the inversion of control patterns that frameworks usually rely on without fighting the language.