Toward Go 2
I should send this to rsc, but it&#x27;s fairly easy to find examples where the lack of generics caused an opportunity cost.<p>(1)  I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago.  I quit.  You can probably guess why from the comments at the top of the file about boxing things with interface{}.  It just got slow and gross, to the point where libcuckoo-go was slower and more bloated than the integrated map type, just because of all the boxing:  <a href="https:&#x2F;&#x2F;github.com&#x2F;efficient&#x2F;go-cuckoo&#x2F;blob&#x2F;master&#x2F;cuckoo.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;efficient&#x2F;go-cuckoo&#x2F;blob&#x2F;master&#x2F;cuckoo.go</a><p>(my research group created libcuckoo.)<p>Go 1.9 offers a native concurrent map type, four years after we looked at getting libcuckoo on go -- because fundamental containers like this really benefit from being type-safe and fast.<p>(2)  I chose to very tightly restrict the initial set of operations we initially accepted into the TensorFlow Go API because there was no non-gross way that I could see to manipulate Tensor types without adding the syntactic equivalent of the bigint library, where everything was Tensor.This(a, b), and Tensor.That(z, q).  <a href="https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1237" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1237</a>
and <a href="https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1771" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1771</a><p>I love go, but the lack of generics simply causes me to look elsewhere for certain large classes of development and research.  We need them.