5 ms·

tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.

by arihant 11y ago

snuxoll 11y ago
And still no generics. Honestly, at this point I just wish they'd add a 'void' alias for 'interface {}' so at least non-typesafe code was only as ugly as the equivalent C -_-
- arihant 11y ago
  Russ Cox said this year that generics aren't left out because of political reasons or design choice. They are left out because of technical constraints which are: - Generics in current form won't work across the board with all parts of Go. - Generics of form that will work for Go across the board are not technically trivial. Honestly, I appreciate Go's philosophy of not implementing until fully understood and accepted. Besides, Go's primary design principle is that of composability. So you're using reflection in one form or another. Achieving generic behaviour with interface and reflection is much more consistent than generics as we know from other languages.
  - bsaul 11y ago
    Purely out of curiosity, do you know of any talk that would explain in detail why things like swift's protocol extension can be implemented in conjunction with generics, and go interfaces can't ? From the outside, the two features (swift's protocol with extensions and go interfaces) seem a bit close, so that made me wonder. I didn't have the time to think too much in detail about it, so i'm just wondering if anybody already had.
    - pcwalton 11y ago
      You certainly can implement Go-like interfaces alongside generics. There's nothing inconsistent about them.
      - arihant 11y ago
        Yes, but the typical consequences that arise out of that do not fit with design goals of Go. Just off the top of my head - boxed types, for example lead to Java-style inheritance patterns. This sits awfully with composability and readability of Go code. You read Go code like a tree. You read Java code as multiply linked list.
    - crawshaw 11y ago
      It can be done, the question is can it be done in a way that fits with everything else in Go? There are technical drawbacks in the implementation of parametric polymorphism that don't suit Go's design goals: http://research.swtch.com/generic http://research.swtch.com/generic.
      - coldtea 11y ago
        All of the supposed reasons given in that post have been answered to death by multiple people (including PL experts), and none holds to much scrutiny. "We just can't be bothered" or "we don't think they're much good, and we don't have a need for them" would be a much more realistic answer.
        crawshaw 11y ago
        I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. Go isn't interested in either being slow. Any generics solution has to have fast runtime, because they need to replace the builtin parametric slices and maps. And the compiler is already too slow, in fact there's a lot of work slated to try and make it faster. Lots of effort went into studying the problem, so it most definitely isn't an issue of "can't be bothered".
        pcwalton 11y ago
        > I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. I think the error in that reasoning is attributing this issue to generics specifically when this is actually a problem with code reuse in general. Say I have a linked list and want to use it to hold both integers or strings. My two options, in any language—whether that language has generics or not—are: (1) write specialized code for every type I want to use it with (go generate), potentially bloating the code and resulting in extra compilation time; (2) use some sort of existential type (interface{} in Go) and share the code but pay a performance cost at runtime. The dilemma arises because of the problem itself, not because of generics. It is of course right that there is a tradeoff here (although there are many other potential solutions that aren't at one extreme or the other, .NET-style JIT compilation or intensional type analysis for example). But not having generics doesn't eliminate the tradeoff. Generics are just a way for the compiler to automate the work that a programmer would otherwise have to do. If you don't have generics, you still have that dilemma, except that you have to write the code yourself instead of the compiler doing it for you.
  - coldtea 11y ago
    >Russ Cox said this year that generics aren't left out because of political reasons or design choice. They've been saying that from the begining. There are no real technical constraints, it's been done in all kinds of languages and it has been a well understood feature for 2+ decades. They just don't want to do the compromises needed, while letting the developers continue to deal with all of them... See also pcwalton's (of Rust fame) comment below.
    - skybrian 11y ago
      They've been solved for many other languages but not for Go. The lessons learned don't necessarily translate well between languages, because different problems need to be solved. Each language is a bag of features that need to work well with all the other features included in the language.
      - coldtea 11y ago
        Do you find Go imposing any special set of contraints? If anything is far less featureful and Algol-like than most of the other languages that have found a way to fit Generics.
        ansible 11y ago
        Go does have some things like interfaces that don't work quite like they do in other languages. I have yet to see a full technical proposal that integrates well with the existing language features and has no nasty corner cases. If such a thing existed, I'd be among the first to stand up and applaud it. The best solution currently (IMHO), is code generation with things like gen [1]. Though I have yet to use that in a real project, so I can't say for sure it is actually the best solution. [1] https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/
        skybrian 11y ago
        As far as I know it's not that something couldn't be shoehorned in, but rather that the language designers' tastes result in additional technical constraints. Apparently they don't want to support only boxed types (like Java), and they also don't want to generate multiple implementations of each generic function for each size, resulting in code bloat (like C++), or to generate code at runtime (like, say, Julia). You could argue that they should just make a choice and go with it because generics are so important, and some language designers would do that, but then these differences in design goals are why we have different languages in the first place. This is based on an early article by Russ Cox [1]; I don't know how the teams' position has evolved since then. [1] http://research.swtch.com/generic http://research.swtch.com/generic
- aikah 11y ago
  AFAIK you can create a named type from interface{} type V interface{} Don't hold your breath when it comes to generics. There is no way they can retrofit them without breaking the language, it's too late. Even features like covariance or unions are just out of question. An option would be to write a super-set of Go with generics that would compile to Go code. what it would do basically is use interface{} everywhere the variable type T is required and insert type assertions for the user. Been thinking about that.
  - snuxoll 11y ago
    > An option would be to write a super-set of Go with generics that would compile to Go code. what it would do basically is use interface{} everywhere the variable type T is required and insert type assertions for the user. Been thinking about that. I think that's pretty much how you'd want to do it, it's type erasure just like generics in Java - sure, some people complain about not having reified generics, but I'm more concerned about type-safety, Go already has some runtime reflection capabilities anyway.
  - ninkendo 11y ago
    > An option would be to write a super-set of Go with generics that would compile to Go code. You could call it go++! (But seriously, that's pretty much what C++ did to C.)
- melling 11y ago
  Were you surprised. They've said generics won't appear before 2.0, and they may never appear. We have this discussion after every minor release. 1.6 will be released in December. See you then.

tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.

by arihant 11y ago

tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.

snuxoll 11y ago

And still no generics. Honestly, at this point I just wish they'd add a 'void' alias for 'interface {}' so at least non-typesafe code was only as ugly as the equivalent C -_-

arihant 11y ago
Russ Cox said this year that generics aren't left out because of political reasons or design choice. They are left out because of technical constraints which are: - Generics in current form won't work across the board with all parts of Go. - Generics of form that will work for Go across the board are not technically trivial. Honestly, I appreciate Go's philosophy of not implementing until fully understood and accepted. Besides, Go's primary design principle is that of composability. So you're using reflection in one form or another. Achieving generic behaviour with interface and reflection is much more consistent than generics as we know from other languages.
- bsaul 11y ago
  Purely out of curiosity, do you know of any talk that would explain in detail why things like swift's protocol extension can be implemented in conjunction with generics, and go interfaces can't ? From the outside, the two features (swift's protocol with extensions and go interfaces) seem a bit close, so that made me wonder. I didn't have the time to think too much in detail about it, so i'm just wondering if anybody already had.
  - pcwalton 11y ago
    You certainly can implement Go-like interfaces alongside generics. There's nothing inconsistent about them.
    - arihant 11y ago
      Yes, but the typical consequences that arise out of that do not fit with design goals of Go. Just off the top of my head - boxed types, for example lead to Java-style inheritance patterns. This sits awfully with composability and readability of Go code. You read Go code like a tree. You read Java code as multiply linked list.
  - crawshaw 11y ago
    It can be done, the question is can it be done in a way that fits with everything else in Go? There are technical drawbacks in the implementation of parametric polymorphism that don't suit Go's design goals: http://research.swtch.com/generic http://research.swtch.com/generic.
    - coldtea 11y ago
      All of the supposed reasons given in that post have been answered to death by multiple people (including PL experts), and none holds to much scrutiny. "We just can't be bothered" or "we don't think they're much good, and we don't have a need for them" would be a much more realistic answer.
      - crawshaw 11y ago
        I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. Go isn't interested in either being slow. Any generics solution has to have fast runtime, because they need to replace the builtin parametric slices and maps. And the compiler is already too slow, in fact there's a lot of work slated to try and make it faster. Lots of effort went into studying the problem, so it most definitely isn't an issue of "can't be bothered".
        pcwalton 11y ago
        > I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. I think the error in that reasoning is attributing this issue to generics specifically when this is actually a problem with code reuse in general. Say I have a linked list and want to use it to hold both integers or strings. My two options, in any language—whether that language has generics or not—are: (1) write specialized code for every type I want to use it with (go generate), potentially bloating the code and resulting in extra compilation time; (2) use some sort of existential type (interface{} in Go) and share the code but pay a performance cost at runtime. The dilemma arises because of the problem itself, not because of generics. It is of course right that there is a tradeoff here (although there are many other potential solutions that aren't at one extreme or the other, .NET-style JIT compilation or intensional type analysis for example). But not having generics doesn't eliminate the tradeoff. Generics are just a way for the compiler to automate the work that a programmer would otherwise have to do. If you don't have generics, you still have that dilemma, except that you have to write the code yourself instead of the compiler doing it for you.
- coldtea 11y ago
  >Russ Cox said this year that generics aren't left out because of political reasons or design choice. They've been saying that from the begining. There are no real technical constraints, it's been done in all kinds of languages and it has been a well understood feature for 2+ decades. They just don't want to do the compromises needed, while letting the developers continue to deal with all of them... See also pcwalton's (of Rust fame) comment below.
  - skybrian 11y ago
    They've been solved for many other languages but not for Go. The lessons learned don't necessarily translate well between languages, because different problems need to be solved. Each language is a bag of features that need to work well with all the other features included in the language.
    - coldtea 11y ago
      Do you find Go imposing any special set of contraints? If anything is far less featureful and Algol-like than most of the other languages that have found a way to fit Generics.
      - ansible 11y ago
        Go does have some things like interfaces that don't work quite like they do in other languages. I have yet to see a full technical proposal that integrates well with the existing language features and has no nasty corner cases. If such a thing existed, I'd be among the first to stand up and applaud it. The best solution currently (IMHO), is code generation with things like gen [1]. Though I have yet to use that in a real project, so I can't say for sure it is actually the best solution. [1] https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/
      - skybrian 11y ago
        As far as I know it's not that something couldn't be shoehorned in, but rather that the language designers' tastes result in additional technical constraints. Apparently they don't want to support only boxed types (like Java), and they also don't want to generate multiple implementations of each generic function for each size, resulting in code bloat (like C++), or to generate code at runtime (like, say, Julia). You could argue that they should just make a choice and go with it because generics are so important, and some language designers would do that, but then these differences in design goals are why we have different languages in the first place. This is based on an early article by Russ Cox [1]; I don't know how the teams' position has evolved since then. [1] http://research.swtch.com/generic http://research.swtch.com/generic
aikah 11y ago
AFAIK you can create a named type from interface{} type V interface{} Don't hold your breath when it comes to generics. There is no way they can retrofit them without breaking the language, it's too late. Even features like covariance or unions are just out of question. An option would be to write a super-set of Go with generics that would compile to Go code. what it would do basically is use interface{} everywhere the variable type T is required and insert type assertions for the user. Been thinking about that.
- snuxoll 11y ago
  > An option would be to write a super-set of Go with generics that would compile to Go code. what it would do basically is use interface{} everywhere the variable type T is required and insert type assertions for the user. Been thinking about that. I think that's pretty much how you'd want to do it, it's type erasure just like generics in Java - sure, some people complain about not having reified generics, but I'm more concerned about type-safety, Go already has some runtime reflection capabilities anyway.
- ninkendo 11y ago
  > An option would be to write a super-set of Go with generics that would compile to Go code. You could call it go++! (But seriously, that's pretty much what C++ did to C.)
melling 11y ago
Were you surprised. They've said generics won't appear before 2.0, and they may never appear. We have this discussion after every minor release. 1.6 will be released in December. See you then.