4 ms·
I'm curious, what makes you think frameworks are an antipattern in Go? What is fundamentally wrong with creating a framework with specific goals around perform
by codezero 10y ago
I'm curious, what makes you think frameworks are an antipattern in Go?
What is fundamentally wrong with creating a framework with specific goals around performance and API?
If Go's stdlib were so comprehensive such that frameworks were not necessary, I would get your point, but it's my understanding Go exists as a simple language on which to build larger programs, not as a "one true way" language with everything included.
- stirner 10y ago> it's my understanding Go exists as a simple language on which to build larger programs, not as a "one true way" language with everything included. I agree. However, there is a big difference between libraries and frameworks. I believe frameworks are an antipattern in any language, not just Go, but Go's emphasis on simplicity makes frameworks for it especially grating to me. Rather than poorly summarize, I'll link two of my favorite articles criticizing frameworks; one is humorous [1] and the other is more serious [2]. [1] http://discuss.joelonsoftware.com/?joel.3.219431.12 http://discuss.joelonsoftware.com/?joel.3.219431.12 [2] http://tomasp.net/blog/2015/library-frameworks/ http://tomasp.net/blog/2015/library-frameworks/
- codezero 10y agoThanks for the links. I misunderstood your displeasure with frameworks as an issue with Go, it makes more sense that you (and many others) see frameworks as bad. The arguments against them are pretty compelling, but I can't fault someone for building one :P
- weberc2 10y agoYou're missing the distinction between frameworks and libraries. Libraries are the preferred way to reuse code in Go. Generally, libraries have a "do one thing well" approach and can be easily swapped out; frameworks try to do everything, and they tend to try to integrate more deeply into your application (which makes them harder to swap out).