6 ms·
>They deliberately ignored proven concepts in programming language design Not really. Generics, as a standalone feature, is not useful for much more than just
by F-0X 7y ago
>They deliberately ignored proven concepts in programming language design
Not really. Generics, as a standalone feature, is not useful for much more than just container types. Go has generic container types, so woot, no need for plain generics.
Languages like Haskell which utilise generics for more useful things do so with other features. In Haskell's case, it's typeclasses, in other languages, it might be operator overloading. If you have a type T, you can't do shit with it unless you know something more about it. A type T that has a notion of + though can be checked at compile time and functions can "add" generically.
Well Go has interfaces. You can stick an Add() method on all the structs you might want to pass "generically" to a function, and add them.
So indeed, Go certainly is much simpler for having skipped "proper" generics, since they get to skip all the complicated stuff that makes them actually useful.
- morelisp 7y ago> Go has generic container types, so woot, no need for plain generics. There are dozens of common types that give the lie to this (the standard Go claim), like sync.Map, sync.Value, lru, or pool. Type classes are a feature that arises from having generics, not one that you need to take advantage of generics.