Consider the document that Ian Lance Taylor put out: https://github.com/golang/proposal/blob/master/design/15292/...
More research here: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...
I have also given it a bit of thinking on the tradeoffs: https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-tho...
The Go community may be stuck on an analysis paralysis mode, but it's much better than ad hoc implementation that will stay forever.
Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor".
That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...
This for example, is my experiment with trying to give Go a backing calculus that supports generics https://asciinema.org/a/166748
The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too - essentially a different language
Well, isn't it a major typesystem change? Makes sense for it to apply to a big part of the runtime and semantics.
"measure twice, think twice, cut once"
(or even "think twice, cut once" if you want to generalise it to other spheres)
"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
https://go.googlesource.com/proposal/+/master/design/go2draf...
Even the ideas that eventually die on the Web, C++, Java and .NET happen to have preview implementations available to try out at one point, instead of dead paper.
People who need generics will use code generation until the issue is addressed, I don't really see the need to rush.
Attention to details is something I like about go.
The big reason for me to use GO is it's simplicity. I can pick any programmer, give him a few days to a week, and he will be productive.
Python used to be somewhat simple (never really that simple) with goal of having 1 "obvious" way of doing anything.
I think GO is better at that, than python ever was, and I think that is one of the bigger reasons for it's success.