10 ms·

If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that no

by dmit 10y ago

If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo. Generics are not free, they bring a lot of baggage with them. And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all.

coldtea 10y ago
>If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved Only everybody who asks for generics knows that, and still wants them to go through and pay the price. 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". >And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all. In the same sense C has achieved quite a lot with buffer overflows, so what's the point in something like Rust?
- dmit 10y ago
  >Only everybody who asks for generics knows that, and still wants them to go through and pay the price. And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Programming languages are not all placed on a single Bad<---->Good scale. There are many variables involved, and it makes sense to have local maxima like Java, Go, Clojure, C, Haskell, etc.
  - coldtea 10y ago
    >And those people are outnumbered by people who are comfortable and productive with the current Go implementation. The only way to know that would be to be able to compare one implementation with and one without generics. But only one Go implementation exists. Perhaps there's some toy attempt by someone, but not anything that is equal in all other aspects to mainland Go but with Generics on top. Plus, since most of the burden falls on the compiler writers and most of the benefits to end users, it just takes the compiler writers to be "comfortable with the current Go implementation" for this to continue to remain Generic-less.
    - dmit 10y ago
      Here's a question for you: what if the Go team add user-defined generic types to the language, and people start demanding HKTs? What then? Do you implement them and hope nobody asks for dependent types? Where do you draw the line?
      - coldtea 10y ago
        Well, it's a soristic problem, but there are some clear heuristics: 1) tons of people have asked for Generics, few have asked for HKTs. 2) C++, C# and Java, programming languages with millions of users and extremely battle tested have Generics, no mainstream language at that level offers HKTs. 3) As a result of (2) a ton more people are familiar with Generics than HKTs, and so the latter are much less probable to be requested. And of course, if they do add Generics, and people ask for HKTs, they should consider what they do about that then and there, not now. No reason to never make a step towards somewhere just because you might (or will) be asked to also take a further one. Except if they believe that they are already at some optimal point (which is my case I think).
        dmit 10y ago
        What about all those people who came to Go from Python, JavaScript, Ruby and whatnot? They are mostly content with the current status quo, generics would just make the learning cliff steeper for them. And according to the Go devs, more people come to Go from Python than from, say, C++. So perhaps it makes sense to stay at that level, at least for now? All I'm saying is this doesn't seems like a simple equation to me. There are many possible solutions to the problem of building large, correct, maintainable, performant programs - and neither of the existing ones looks like a surefire winner given all the limitations.
        grey-area 10y ago
        Indeed, not many developers have moved from C++ to Go, though there are a few from Java who might miss generics. Here is some recent data on this: https://golangnews.com/stories/1490-results-of-the-gopher-language-poll https://golangnews.com/stories/1490-results-of-the-gopher-la...
  - openasocket 10y ago
    > And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Citation needed. How do we know that the majority of Go users would prefer not to have generics? How do we know the number of non-Go users would be willing to use Go if it had generics is insignificant? Is there some large scale survey of Go users somewhere you can cite?
  - lokedhs 10y ago
    > And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Of course they are. The people who are not comfortable with the current implementation aren't using Go. It's a fallacy to only look at what the major users wants. It's similar to the “faster horses” fallacy.
    - codygman 10y ago
      > Of course they are. The people who are not comfortable with the current implementation aren't using Go. Not true. What about those who write Go at work for instance?
      - lokedhs 10y ago
        Of course, but there is a set of people who would be willing to use Go for new projects, but are not doing so because of this and other reasons.
- eternalban 10y ago
  > 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.
hota_mazi 10y ago
> Go has achieved a lot of success without them This is a dangerous and slippery slope to engage on. Java was also extremely successful in 2004, before it supported generics. Yet you'd be hard pressed to find a Java developer who thinks that generics were not overwhelmingly beneficial to the language, and probably one of the main reasons why Java is even more dominant and powerful today than it was pre-generics.
- geodel 10y ago
  For my purpose generics in Java are not overwhelmingly useful. I work on a quite big and successful, Java application inside our company. And it was written mostly after Java 1.5 but hardly use much of generics. It may have many issues but none related to generic. I am not saying generic are not useful. But I have not found enormous use of Generics in typical Java business application. The most common generic data structure I have used in Java are Maps and lists which are already generic in Go.
  - hota_mazi 10y ago
    I think you are underestimating the indirect effect that generics have had on your code, even if you don't use them directly yourself. Thanks to generics, millions of lines of code in libraries that you are using became safer and faster, and you are benefiting from this, even if it's not apparent to you. Basically, generics made Java a better and safer language. Both theoretically and practically.
- hodgesrm 10y ago
  I have been a Java developer since the JDK alpha in 1995. It was apparent then that Java was going to be pretty big due to the fact it was VM-based, addressed a lot of pain points like platform independence/concurrency/interfaces/etc., and was similar enough to C/C++ that people would adapt to it quickly. The language experienced an enormous network effect due to the tooling and support libraries that allowed Java to become dominant in enterprise development. It's hard to argue that a feature that appeared a decade later changed the equation all that much. I like generics but would still use Java even if they did not exist. In my work the concurrency features are far more important.
libria 10y ago
Modern languages like Rust and D are being designed with generics and people are supposedly paying some prime for that complexity. I wonder if anyone using generics in their language would give them up for some increase in performance or language simplicity. It's doubtful. Internally, the Go team has drawn up proposals for adding generics [1] but rejected them because of drawbacks. Hopefully one day we can see those drawbacks, because maybe a lot of us are more than happy to pay that price. [1] https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03tsxw/ https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...
- valarauca1 10y ago
  Hopefully one day we can see those drawbacks One of the main issues with Go is that we can't see those discussions. With C++, C, Rust, D, Java those proposals are public from Start to Finish. From the discussions I've seen on what Go considers complicated I'd bet it work out to be something like name mangling. Go turns off ASLR for loaded C code because its easier to debug. Which is really only true if your debugging process requires memorizing the absolute address of symbols that control flow will jump too. I guess that is useful if you are reading the raw hex streams. Name Mangling is complicating things because you can no-longer debug with ElfRead. Go seems to reject anything that was invented after the ~70's. As those concepts are complicated. I can't help but feel that Thompson and Pike just don't want to change the bad habits they've developed from by-gone ages and adopt modern tooling.
- mseepgood 10y ago
  > Hopefully one day we can see those drawbacks, because maybe a lot of us are more than happy to pay that price. Why wait for "one day"? These proposals are public: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
- burntsushi 10y ago
  Rust without generics would not work well. (FWIW, I consider Go quite usable and enjoy using it.) The reason is that Rust very much depends on building up safe abstractions around data structures with unsafe implementations. Without generics, folks would need to re-implement those data structures and `unsafe` would become profligate, which diminishes Rust's core value proposition.
camus2 10y ago
> If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo They should have thought about it at the very beginning of Go design. it's easy to say now "We didn't find a good way to implement generics" when their design choices made implementing generics insanely hard at first place. Well actually,they thought about it, where does append,delete,make and co come from? how do these functions know their arguments and return types at compile time? generics. Furthermore it's not all or nothing. Go could have supported parametric functions in user land just like append,make or delete without implementing full-on generics. They just don't want to bother with that, because it's impossible to retrofit generics now without breaking the reflect package. The rest is just excuses to evade the issue. > Generics are not free Creating a modern statically typed language WITHOUT generics isn't free either. Just like implicit interfaces are not free, just like the reflect package is not free, just like using interface{} somewhere isn't free, just like telling people to use code generators isn't free.
- biztos 10y ago
  I thought the special pass given to append, make, and delete depends on the special nature of slices and maps. That is, a []Whatever is not as opaque as a Whatever{} or an interface{}. Same with a map[Foo]Bar, you (you being Go) know it's a map. (I have no opinion on whether Go should have generics, I just think the apparent exceptions make sense even if they might seem unfair.)
  - camus2 10y ago
    Your argument doesn't explain why a programmer cannot implement his own append or delete functions on existing container types. These exceptions do not make sense.
runT1ME 10y ago
The argument is more along the lines of "the upsides of Generics are known, and the downsides are that many of our users will find them confusing". That pretty much says what you need to know about the language.
kmicklas 10y ago
That's just not true, there are not tradeoffs that aren't solved multiple decades ago. Go implementors are lazy and dogmatic.
- grey-area 10y ago
  This discussion of generics and the tradeoffs doesn't strike me as either lazy or dogmatic. Have you read it? https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
  - kmicklas 10y ago
    Yes. It's absurd. Dogmatic isn't a great word to describe it but how can you live in 2016 and not read it as lazy?
serge2k 10y ago
How many years has it been and they still haven't come up with anything? Go doesn't have generics because they don't want them.

by dmit 10y ago

coldtea 10y ago

>If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved Only everybody who asks for generics knows that, and still wants them to go through and pay the price. 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". >And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all. In the same sense C has achieved quite a lot with buffer overflows, so what's the point in something like Rust?

dmit 10y ago
>Only everybody who asks for generics knows that, and still wants them to go through and pay the price. And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Programming languages are not all placed on a single Bad<---->Good scale. There are many variables involved, and it makes sense to have local maxima like Java, Go, Clojure, C, Haskell, etc.
- coldtea 10y ago
  >And those people are outnumbered by people who are comfortable and productive with the current Go implementation. The only way to know that would be to be able to compare one implementation with and one without generics. But only one Go implementation exists. Perhaps there's some toy attempt by someone, but not anything that is equal in all other aspects to mainland Go but with Generics on top. Plus, since most of the burden falls on the compiler writers and most of the benefits to end users, it just takes the compiler writers to be "comfortable with the current Go implementation" for this to continue to remain Generic-less.
  - dmit 10y ago
    Here's a question for you: what if the Go team add user-defined generic types to the language, and people start demanding HKTs? What then? Do you implement them and hope nobody asks for dependent types? Where do you draw the line?
    - coldtea 10y ago
      Well, it's a soristic problem, but there are some clear heuristics: 1) tons of people have asked for Generics, few have asked for HKTs. 2) C++, C# and Java, programming languages with millions of users and extremely battle tested have Generics, no mainstream language at that level offers HKTs. 3) As a result of (2) a ton more people are familiar with Generics than HKTs, and so the latter are much less probable to be requested. And of course, if they do add Generics, and people ask for HKTs, they should consider what they do about that then and there, not now. No reason to never make a step towards somewhere just because you might (or will) be asked to also take a further one. Except if they believe that they are already at some optimal point (which is my case I think).
      - dmit 10y ago
        What about all those people who came to Go from Python, JavaScript, Ruby and whatnot? They are mostly content with the current status quo, generics would just make the learning cliff steeper for them. And according to the Go devs, more people come to Go from Python than from, say, C++. So perhaps it makes sense to stay at that level, at least for now? All I'm saying is this doesn't seems like a simple equation to me. There are many possible solutions to the problem of building large, correct, maintainable, performant programs - and neither of the existing ones looks like a surefire winner given all the limitations.
        grey-area 10y ago
        Indeed, not many developers have moved from C++ to Go, though there are a few from Java who might miss generics. Here is some recent data on this: https://golangnews.com/stories/1490-results-of-the-gopher-language-poll https://golangnews.com/stories/1490-results-of-the-gopher-la...
- openasocket 10y ago
  > And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Citation needed. How do we know that the majority of Go users would prefer not to have generics? How do we know the number of non-Go users would be willing to use Go if it had generics is insignificant? Is there some large scale survey of Go users somewhere you can cite?
- lokedhs 10y ago
  > And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Of course they are. The people who are not comfortable with the current implementation aren't using Go. It's a fallacy to only look at what the major users wants. It's similar to the “faster horses” fallacy.
  - codygman 10y ago
    > Of course they are. The people who are not comfortable with the current implementation aren't using Go. Not true. What about those who write Go at work for instance?
    - lokedhs 10y ago
      Of course, but there is a set of people who would be willing to use Go for new projects, but are not doing so because of this and other reasons.
eternalban 10y ago
> 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.

hota_mazi 10y ago

> Go has achieved a lot of success without them This is a dangerous and slippery slope to engage on. Java was also extremely successful in 2004, before it supported generics. Yet you'd be hard pressed to find a Java developer who thinks that generics were not overwhelmingly beneficial to the language, and probably one of the main reasons why Java is even more dominant and powerful today than it was pre-generics.

geodel 10y ago
For my purpose generics in Java are not overwhelmingly useful. I work on a quite big and successful, Java application inside our company. And it was written mostly after Java 1.5 but hardly use much of generics. It may have many issues but none related to generic. I am not saying generic are not useful. But I have not found enormous use of Generics in typical Java business application. The most common generic data structure I have used in Java are Maps and lists which are already generic in Go.
- hota_mazi 10y ago
  I think you are underestimating the indirect effect that generics have had on your code, even if you don't use them directly yourself. Thanks to generics, millions of lines of code in libraries that you are using became safer and faster, and you are benefiting from this, even if it's not apparent to you. Basically, generics made Java a better and safer language. Both theoretically and practically.
hodgesrm 10y ago
I have been a Java developer since the JDK alpha in 1995. It was apparent then that Java was going to be pretty big due to the fact it was VM-based, addressed a lot of pain points like platform independence/concurrency/interfaces/etc., and was similar enough to C/C++ that people would adapt to it quickly. The language experienced an enormous network effect due to the tooling and support libraries that allowed Java to become dominant in enterprise development. It's hard to argue that a feature that appeared a decade later changed the equation all that much. I like generics but would still use Java even if they did not exist. In my work the concurrency features are far more important.

libria 10y ago

Modern languages like Rust and D are being designed with generics and people are supposedly paying some prime for that complexity. I wonder if anyone using generics in their language would give them up for some increase in performance or language simplicity. It's doubtful. Internally, the Go team has drawn up proposals for adding generics [1] but rejected them because of drawbacks. Hopefully one day we can see those drawbacks, because maybe a lot of us are more than happy to pay that price. [1] https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03tsxw/ https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...

valarauca1 10y ago
Hopefully one day we can see those drawbacks One of the main issues with Go is that we can't see those discussions. With C++, C, Rust, D, Java those proposals are public from Start to Finish. From the discussions I've seen on what Go considers complicated I'd bet it work out to be something like name mangling. Go turns off ASLR for loaded C code because its easier to debug. Which is really only true if your debugging process requires memorizing the absolute address of symbols that control flow will jump too. I guess that is useful if you are reading the raw hex streams. Name Mangling is complicating things because you can no-longer debug with ElfRead. Go seems to reject anything that was invented after the ~70's. As those concepts are complicated. I can't help but feel that Thompson and Pike just don't want to change the bad habits they've developed from by-gone ages and adopt modern tooling.
mseepgood 10y ago
> Hopefully one day we can see those drawbacks, because maybe a lot of us are more than happy to pay that price. Why wait for "one day"? These proposals are public: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
burntsushi 10y ago
Rust without generics would not work well. (FWIW, I consider Go quite usable and enjoy using it.) The reason is that Rust very much depends on building up safe abstractions around data structures with unsafe implementations. Without generics, folks would need to re-implement those data structures and `unsafe` would become profligate, which diminishes Rust's core value proposition.

camus2 10y ago

> If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo They should have thought about it at the very beginning of Go design. it's easy to say now "We didn't find a good way to implement generics" when their design choices made implementing generics insanely hard at first place. Well actually,they thought about it, where does append,delete,make and co come from? how do these functions know their arguments and return types at compile time? generics. Furthermore it's not all or nothing. Go could have supported parametric functions in user land just like append,make or delete without implementing full-on generics. They just don't want to bother with that, because it's impossible to retrofit generics now without breaking the reflect package. The rest is just excuses to evade the issue. > Generics are not free Creating a modern statically typed language WITHOUT generics isn't free either. Just like implicit interfaces are not free, just like the reflect package is not free, just like using interface{} somewhere isn't free, just like telling people to use code generators isn't free.

biztos 10y ago
I thought the special pass given to append, make, and delete depends on the special nature of slices and maps. That is, a []Whatever is not as opaque as a Whatever{} or an interface{}. Same with a map[Foo]Bar, you (you being Go) know it's a map. (I have no opinion on whether Go should have generics, I just think the apparent exceptions make sense even if they might seem unfair.)
- camus2 10y ago
  Your argument doesn't explain why a programmer cannot implement his own append or delete functions on existing container types. These exceptions do not make sense.

runT1ME 10y ago

The argument is more along the lines of "the upsides of Generics are known, and the downsides are that many of our users will find them confusing". That pretty much says what you need to know about the language.

kmicklas 10y ago

That's just not true, there are not tradeoffs that aren't solved multiple decades ago. Go implementors are lazy and dogmatic.

grey-area 10y ago
This discussion of generics and the tradeoffs doesn't strike me as either lazy or dogmatic. Have you read it? https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
- kmicklas 10y ago
  Yes. It's absurd. Dogmatic isn't a great word to describe it but how can you live in 2016 and not read it as lazy?

serge2k 10y ago

How many years has it been and they still haven't come up with anything? Go doesn't have generics because they don't want them.