|
|
|
|
|
|
by ainar-g
2374 days ago
|
|
|
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. |
|
|
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.