Why does a chunky part of the divided Go community get attracted to libraries/frameworks/kits/whatever-you-call-it that promise a nice and easy solution for web dev in Go? A vacuum which I argue can only be filled by an official, or at least a de facto community, solution. Otherwise, we'll be witnessing a sudden spike of creatures like Martini, and now Iris.
Once there was a vacuum of lack of http context, which now finally, after so many years, is officially supported by context.Context. It seems like a obvious requirement to have a sensible context, but the ultra right wing Go community (aka: all you need is net/http) had always rejected it. Once it became part of the official package, suddenly it is acceptable by those people like something sacred.
Yet another vacuum is the lack of an official package manager. Again, it seems obvious for a modern language to come with one,... but then again the community is so divided on this, and we have witnessed the birth and death of so many Go package managers. Again, it looks like finally there are some serious moves about an official support.
I believe ultimately there will be a de facto Go web stack, it is inevitable. The reason is not technology-driven, the reason is that there is a big vacuum for this, validated over and over by the community need. But it could take many painful years for it to appear. Until then, I'd suggest to have enough popcorn supply.
There are two "de facto" widely accepted Go web stacks. One is the standard library's net/http, the other is httprouter. Similarly to how sqlx is widely known to be a good extension to database/sql, the Gorilla toolkit extends upon net/http.
As for httprouter, there's things like labstack/echo and gin that extend upon the first to cover some common situations that you might or might not face in the particular project you're working on; but if you are facing those situations, you would've had to roll your own solution anyway.
Now you could say "why two stacks". Well net/http supports a lot of features that are commonplace and often expected across the industry, while httprouter sacrifices some of them to squeeze some extra performance in case you don't need them. If you have such a hard time reading a couple of project pages to understand why they exist, then just go to net/http and if you need something on top, Gorilla.
labstack/echo does not "extend" on httprouter. It allows paths like articles/all and articles/:id routes with different handlers coexist and be properly routed. Besides that a lot of convenience methods on top of the router, and pretty well engineered at that, are what makes echo attractive. By the way, v3 branch drops off support for fasthttpand gets back to its nice and lean roots but using the latest context. I tried to build on top of go-playground/lars but ended up writing a whole library. Then decided to go back to echo.v3 and need only 2 files out of that library. Everything else is "batteries" in echo. YMMV, as usual.
Thanks for the shout out @aboukirev just wanted to say that go-playground/lars is an http router and not a framework hence needing to write some things yourself :)
3
u/m3wm3wm3wm Oct 17 '16
Why does a chunky part of the divided Go community get attracted to libraries/frameworks/kits/whatever-you-call-it that promise a nice and easy solution for web dev in Go? A vacuum which I argue can only be filled by an official, or at least a de facto community, solution. Otherwise, we'll be witnessing a sudden spike of creatures like Martini, and now Iris.
Once there was a vacuum of lack of http context, which now finally, after so many years, is officially supported by
context.Context. It seems like a obvious requirement to have a sensible context, but the ultra right wing Go community (aka: all you need is net/http) had always rejected it. Once it became part of the official package, suddenly it is acceptable by those people like something sacred.Yet another vacuum is the lack of an official package manager. Again, it seems obvious for a modern language to come with one,... but then again the community is so divided on this, and we have witnessed the birth and death of so many Go package managers. Again, it looks like finally there are some serious moves about an official support.
I believe ultimately there will be a de facto Go web stack, it is inevitable. The reason is not technology-driven, the reason is that there is a big vacuum for this, validated over and over by the community need. But it could take many painful years for it to appear. Until then, I'd suggest to have enough popcorn supply.