Go Experience Report for Generics: Google Metrics API

This is the kind of report Russ Cox asked for, for evaluating the use cases for generics. I'm glad they're being produced.

I think it is worth noting that Sameer Ajmani is the manager for the Go team. While some people like to throw around strawman arguments about the Go team not liking / not seeing the point of generics, they do have first-hand experience that the difficulties from their decision to (at least so far) exclude generics from the language. And if you have a similar experience report; please share it. I think the team wants to get generics "right", but it's a difficult design problem (compiler complexity, compiler speed, binary size, ease of use, fitting in with the language, being simple enough) so feedback will help them understand the problem better.

I reported - in reasonable detail - a similar case study, in Jan 2014: <a href="http:&#x2F;&#x2F;oneofmanyworlds.blogspot.in&#x2F;2014&#x2F;01&#x2F;another-go-at-go-failed.html" rel="nofollow">http:&#x2F;&#x2F;oneofmanyworlds.blogspot.in&#x2F;2014&#x2F;01&#x2F;another-go-at-go-...</a>.<p>It was similar in that the combinations of types quickly led to a ballooning of concrete types that had to be implemented. And, not having those concrete types led to an unacceptably high number of type assertions!<p>Generics would have solved the problem succinctly, while preserving programmer intent.

Or create a struct that holds all anticipated values as pointers. Create setters. Yes the api will be different from the other languages involved but the other languages have generics.<p>In other words there is a solution to the problem that doesn&#x27;t require generics at all.