3 ms·

Go's omission of user-defined generics was a conscious decision by Go authors led by the belief that the benefit is not worth the complexity added and that devs

Go's omission of user-defined generics was a conscious decision by Go authors led by the belief that the benefit is not worth the complexity added and that devs would misuse it; yet this did not hold them back from special casing generic support for things they implemented themselves. This is what I'm comparing it to. What it would take to add generics to Go now is a separate matter. Feel free to link my Go commentary to my point on lack of type classes on Elm if you want to see it from the perspective of changing an existing language.

ghthor 8y ago
I don't think I've ever seen the Golang creators talk about devs misusing generics. It that's ever been said, it's in the context of compile time. The argument has always been about avoiding complexity at compile time, and within the compiler, which I think is a very noble goal.
foldr 8y ago
>yet this did not hold them back from special casing generic support for things they implemented themselves. My point is that essentially all statically typed languages allow parameterization of built-in datatypes. C does this, for example, since it distinguishes arrays of ints from arrays of pointers to ints. No-one usually says that C has generics, special-cased or otherwise. The idea that adding generics is "just" a matter of extending parameterization of arrays to user-defined data types seems to be largely limited to anti-Go rhetoric. The implicit suggestion is that the Go designers could have chosen to allow users to parameterize their own types, but didn't do so because of [insert bad intentions]. In fact, adding a true generic type system to a language is a vastly more complex undertaking than merely allowing parameterization of built-in types. It totally makes sense that a language designer might decide to do the latter but not the former. It's not an arbitrary restriction tacked on because Rob Pike doesn't trust you to use generics correctly.

ghthor 8y ago

I don't think I've ever seen the Golang creators talk about devs misusing generics. It that's ever been said, it's in the context of compile time. The argument has always been about avoiding complexity at compile time, and within the compiler, which I think is a very noble goal.

foldr 8y ago

>yet this did not hold them back from special casing generic support for things they implemented themselves. My point is that essentially all statically typed languages allow parameterization of built-in datatypes. C does this, for example, since it distinguishes arrays of ints from arrays of pointers to ints. No-one usually says that C has generics, special-cased or otherwise. The idea that adding generics is "just" a matter of extending parameterization of arrays to user-defined data types seems to be largely limited to anti-Go rhetoric. The implicit suggestion is that the Go designers could have chosen to allow users to parameterize their own types, but didn't do so because of [insert bad intentions]. In fact, adding a true generic type system to a language is a vastly more complex undertaking than merely allowing parameterization of built-in types. It totally makes sense that a language designer might decide to do the latter but not the former. It's not an arbitrary restriction tacked on because Rob Pike doesn't trust you to use generics correctly.