4 ms·

> The "we'll only add them when there's a solution with no tradeoffs" is a red-herring, like "we'll add them on a day that doesn't end in -y". Russ actually ad

> The "we'll only add them when there's a solution with no tradeoffs" is a red-herring, like "we'll add them on a day that doesn't end in -y". Russ actually addressed this at length: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417

coldtea 10y ago
How is that comment anything but a refusal to move on unless some magic tradeoff free solution appears? It even ends saying that "Programming language researchers are sometimes disappointed that Go hasn’t picked up more of the recent ideas from the literature, but those ideas simply haven’t had time to pass through the filter of practical experience. I believe generics is one of those ideas.". But Generics are neither some new PL topic, nor have they not passed the "filter of practical experience" (millions use them in C++, Java and C# alone). I'd rather they explicitly said: "It will take a total breakthrough in computer science regarding generics implementations for us to consider them for Go, and we wont ever care of paying the costs of any current, viable in practice for millions of programmers in other mainstream languages, approach".
- eternalban 10y ago
  > How is that comment anything but a refusal to move on unless some magic tradeoff free solution appears? Well I (somewhat) agree with that, but my take of it was Russ is basically saying existing approaches "don't work well with Go" and "recent ideas" are "not well understood" with the concern that "there's a princess in another castle after that one I am sure." Or put it another way, per his emphasis on the "engineering" nature of Go, it is not an issue of tradeoffs, rather a concern that a runaway train of complexity will follow. Or if you will excuse my Mexican French, the problem is the fucken type system :)
- majewsky 10y ago
  > How is that comment anything but a refusal to move on unless some magic tradeoff free solution appears? A programming language design is the combination of a set of features. The hard part in designing a language is working out how all these features interact with each other. For example, one feature of Go is that every type has a default value (0 for decimals, nil for pointers, empty string for strings, etc.). This property leads to the inability to include algebraic data types cleanly. To see this, consider this simple ADT (in Haskell syntax): data Either a b = Left a | Right b What's the default type here? It could be "Left(default-value-of-a)" or "Right(default-value-of-b)". You could introduce additional syntax to define the default value, but that increases complexity. You could introduce a rule how the default value is inferred in these cases, but that goes against the Rule of Least Surprise. You could remove the "default value for every type" feature that clashes with ADTs, but that causes problems elsewhere. Therefore Golang lacks ADTs and uses pointers and multiple return values instead.
solidsnack9000 10y ago
How is it that array and map are generic, then?

coldtea 10y ago

How is that comment anything but a refusal to move on unless some magic tradeoff free solution appears? It even ends saying that "Programming language researchers are sometimes disappointed that Go hasn’t picked up more of the recent ideas from the literature, but those ideas simply haven’t had time to pass through the filter of practical experience. I believe generics is one of those ideas.". But Generics are neither some new PL topic, nor have they not passed the "filter of practical experience" (millions use them in C++, Java and C# alone). I'd rather they explicitly said: "It will take a total breakthrough in computer science regarding generics implementations for us to consider them for Go, and we wont ever care of paying the costs of any current, viable in practice for millions of programmers in other mainstream languages, approach".

eternalban 10y ago
> How is that comment anything but a refusal to move on unless some magic tradeoff free solution appears? Well I (somewhat) agree with that, but my take of it was Russ is basically saying existing approaches "don't work well with Go" and "recent ideas" are "not well understood" with the concern that "there's a princess in another castle after that one I am sure." Or put it another way, per his emphasis on the "engineering" nature of Go, it is not an issue of tradeoffs, rather a concern that a runaway train of complexity will follow. Or if you will excuse my Mexican French, the problem is the fucken type system :)
majewsky 10y ago
> How is that comment anything but a refusal to move on unless some magic tradeoff free solution appears? A programming language design is the combination of a set of features. The hard part in designing a language is working out how all these features interact with each other. For example, one feature of Go is that every type has a default value (0 for decimals, nil for pointers, empty string for strings, etc.). This property leads to the inability to include algebraic data types cleanly. To see this, consider this simple ADT (in Haskell syntax): data Either a b = Left a | Right b What's the default type here? It could be "Left(default-value-of-a)" or "Right(default-value-of-b)". You could introduce additional syntax to define the default value, but that increases complexity. You could introduce a rule how the default value is inferred in these cases, but that goes against the Rule of Least Surprise. You could remove the "default value for every type" feature that clashes with ADTs, but that causes problems elsewhere. Therefore Golang lacks ADTs and uses pointers and multiple return values instead.

solidsnack9000 10y ago

How is it that array and map are generic, then?