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: http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-go-....

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!

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.

In other words there is a solution to the problem that doesn't require generics at all.