With regards to growing "the authors knowledge" -- contributing to PostgREST would have done a lot more for them there, since Haskell is quite different from Go.
Maybe, but reimplementations can evolve differently... This is why we have forks and distros, and to some extent linux.
> With regards to growing "the authors knowledge" -- contributing to PostgREST would have done a lot more for them there, since Haskell is quite different from Go.
Your making the mighty assumption that one wants to learn a language, or that the language is good (NOT taking a pot shot at haskell here) or that it makes sense in their environment.
I think you raise some important points however, that do need to be part of the decision to undertake reimplmentaion of something that already exists.
I am not making either of these assumptions at all -- I am only asserting that there is plenty to learn from a typed functional programming language, if it seems difficult at first. That doesn't mean it is good, nor that you want to learn it.
Wise men learn more from fools than fools learn from wise men. Some languages are bad but because they are significantly different from what I learned before, I learned a lot from them.
I have done all of these at one point or another in my career, as well as several others, and I have not been a contributor back to them. These were either know issues with separate fixes and consequences or very specific to the company I was working for at the time.
Do I know C or C++. The answer is not really... However C and C++ (and to some extent java) are pervasive. Haskel doesn't fall into that camp.
If your a Golang shop and you have a need for this, then it might be something you choose incase you need to support it, or tune it or mould it to your needs.
Beyond that, projects like this are GREAT for go. You have a well defined problem space, an existing tool and a reimplementation like this is only going to grow the authors knowledge and expand the Golang universe.