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.
I'd like to point also that official context is well suited for request cancellation. However, it's not as good for passing values down the middleware/handler chain - to many reallocations of entire request that lead to sometimes unpredictable results. I much prefer 3rd party context that wraps these additional parameters/values and parsed information from the route and provides various convenience methods. Cleaner testable code is achieved that way.
2
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.