Look, it's pretty obvious from your comments that you're not a fan of Go, but if you can come to terms with the fact that some people enjoy languages you do not (or their use is mandated by their work environment) then you'll also be able to understand that they would also like certain tools and libraries available to them in that language.

It's not about recreating everything in Go "just because", it's about being a Go developer and wanting those tools to be available to you.

This highlights a bigger problem: why should you have to reimplement the same idea hundreds of times if what you already want to do already exists?

I don't look at it as reinventing the wheel, any more than one would consider the advent of new languages and technologies a reinvention. They're iterations on the concept, bringing that concept into a new environment to be further refined or built upon.

Other threads in this discussion bring up Finagle's shortcomings, partly due to certain features not being addressed or included by Finagle's authors due to them being low priority. In that case what you want may not already exist, but may work as inspiration for another incarnation.

I once saw Douglas Crockford, when asked about JSON in comparison to XML, say "The great thing about reinventing the wheel is that sometimes you get a round one".

I don't think it's _always an_ inferiority complex.

I've personally run into many situations in which porting a lib to Go is easier -- and more efficient -- than my brain's context switching between multiple languages in order to fix issues with the original lib.