I'd argue that at least the author tried to write a real documentation, which 95% of Go library authors don't do.
> the concept of a framework is fundamentally complex and at odds with the goals of Go
The famous "You don't need that with Go ™ ".
It's more like Gophers hate the word "framework","dependency injection" and "orm". It's hardly a framework, it's a router and a middleware stack.
Instead of being enthusiastic about others using their language, like in any other community, Gophers like to hate, shame, mock other people because they didn't do things "the Go way", whatever they think it is. It's one of the most toxic community I have ever seen.
I didn't mean to hate, shame, or mock anyone. I would rather that programmers who create complex antipatterns stay in other languages that encourage them, and if light critique has that side effect, so be it.
I just submitted a PR to fix a few minor issues. In general, the grammar issues here are really minimal and the page seems to communicate the project and its goals very clearly without being too distracting.
I didn't find any explicit typos, like misspelled words, but I didn't look that hard either, hopefully you can help out!
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.
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.
> 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].
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
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).
I'd argue that at least the author tried to write a real documentation, which 95% of Go library authors don't do.
> the concept of a framework is fundamentally complex and at odds with the goals of Go
The famous "You don't need that with Go ™ ".
It's more like Gophers hate the word "framework","dependency injection" and "orm". It's hardly a framework, it's a router and a middleware stack.
Instead of being enthusiastic about others using their language, like in any other community, Gophers like to hate, shame, mock other people because they didn't do things "the Go way", whatever they think it is. It's one of the most toxic community I have ever seen.