3 ms·

Not the parent poster but: a) Type classes/interfaces. b) "Native JS for me, not for thee". Much like Go gatekeeps generics to the language authors only, Elm

Not the parent poster but: a) Type classes/interfaces. b) "Native JS for me, not for thee". Much like Go gatekeeps generics to the language authors only, Elm restricts native JS access only to the language runtime because devs "might get it wrong"; forcing them to use the ports system, where they have to type the use of even perfectly pure JS code as a side effect. c) The official package manager forbids the upload of any package that interacts with JS without the blessing of the BDFL. I'm aware on the tradeoffs of each case, I understand Evan's intentions; but I heavily disagree with them, which is why I don't entertain Elm as an option for production use anymore and would rather go with something like Reason despite being less knowledgeable about it.

foldr 8y ago
>Much like Go gatekeeps generics to the language authors only It would be more accurate simply to say that Go lacks generics. I don't know of many statically typed languages that have arrays but which don't allow you to type an array of integers differently from an array of strings. Go basically has that feature, plus built-in hashtables that are also type parametrizable. Characterizing that as some kind of huffy refusal to allow people other than the language authors to use generics is arguably inaccurate. Adding generics to Go would require fundamental changes to the type system, and would have some nasty interactions with interfaces. It's not a matter of flipping a switch.
- mixedCase 8y ago
  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.

foldr 8y ago

>Much like Go gatekeeps generics to the language authors only It would be more accurate simply to say that Go lacks generics. I don't know of many statically typed languages that have arrays but which don't allow you to type an array of integers differently from an array of strings. Go basically has that feature, plus built-in hashtables that are also type parametrizable. Characterizing that as some kind of huffy refusal to allow people other than the language authors to use generics is arguably inaccurate. Adding generics to Go would require fundamental changes to the type system, and would have some nasty interactions with interfaces. It's not a matter of flipping a switch.

mixedCase 8y ago
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.