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.
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.
But I think people are more concerned about bigger and more complicated frameworks.
Haven't heard that before but I really like it!
Same thing happened to JavaScript, and now the language is ruined, sadly. It's now a crappier, but more widely deployed Ruby.
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?