
Go Experience Report for Generics: Google Metrics API - m0nastic
https://medium.com/@sameer_74231/go-experience-report-for-generics-google-metrics-api-b019d597aaa4
======
euyyn
This is the kind of report Russ Cox asked for, for evaluating the use cases
for generics. I'm glad they're being produced.

------
msingle
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.

------
sigmaml
I reported - in reasonable detail - a similar case study, in Jan 2014:
[http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-
go-...](http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-go-
failed.html).

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.

------
goodbye-
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.

