Re:Google's Go Programming Language Grows Up: Now What?
by colin_jack on Thursday September 20, 2012 @09:59AM
(#4548545)
"I think in real usage (in my experience), this is very rarely the case. The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types"
When working in .NET on framework-y code I use generics with reflection a lot because it makes it easy to remove a whole swathe of repetitive code. Mapping from one object to another using a Mapper<TFrom, TTo> with generic constraints, reflection and some over-ridable conventions springs to mind.
Not an argument for adding generics in Go, or against Go itself as I haven't yet found the time to play with it. However I do think generics can be more useful than people give them credit for.
Re:Google's Go Programming Language Grows Up: Now What?
by earthboundkid on Thursday September 20, 2012 @11:47PM
(#4552102)
The thing is that Go has generics already for the most common data types: slices (vectors, what Python calls 'lists', others call them 'arrays'), channels (iterators, generators), and maps (dictionaries, hashes). Since there's already a built-in map[T1] T2, so you wouldn't need to build it yourself, which saves even more work.
Re:Google's Go Programming Language Grows Up: Now What?
by kd0amg on Friday September 21, 2012 @12:46AM
(#4552337)
If what it has are a handful of special cases baked into the language, saying the language supports it is probably overselling (similarly, having types like `float[3]' doesn't mean we consider C as supporting dependent types).
Re:Google's Go Programming Language Grows Up: Now What?
by pmcjones on Thursday September 20, 2012 @06:37PM
(#4551127)
"The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types." Take a look at C++'s STL: a large set of generic algorithms that work with any data structure (built-in or user-written) supporting the standard iterator protocols. Many people think of STL as "a bunch of container classes", and ignore the algorithms.
Also, I tend to appreciate Go's approach of writing more code in these situations, because in general the code is still far more readable than a C++ Template (for example).
The Go creators have not ruled out adding Generics, they are simply being very careful about how they implement it. I would rather have this situation than something like a generic Java/C#/C++ style generics implementation rammed in because it is demanded by people who have hardly touched the language (or refuse to touch it until said feature is added).