4 ms·

Really, the typo thing was not the main point of my original comment, it was just an aside. I'm sorry to anyone I have offended. I mainly take issue with the p

by stirner 10y ago

Really, the typo thing was not the main point of my original comment, it was just an aside. I'm sorry to anyone I have offended. I mainly take issue with the proliferation of Go frameworks, especially HTTP frameworks. Frameworks are an antipattern and there are already a huge number of HTTP frameworks that are all incompatible and reimplement the same functionality. I don't think this is useful for the language and in fact think it hurts it.

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 ago
    Thanks 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 ago
  You'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).

by stirner 10y ago

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 ago
  Thanks 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 ago
You'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).