3 ms·

Looks a lot simpler than contracts... I'm much happier with the aesthetics of using interfaces for generic constraints. Looks a lot simpler to use. Besides, it'

Looks a lot simpler than contracts... I'm much happier with the aesthetics of using interfaces for generic constraints. Looks a lot simpler to use. Besides, it's completely compatible with existing code, only a minor update will be required. Seems to me to be one of those features people will ignore if they don't want but love in the instances where there would otherwise be lots of boilerplate and/or generated code.

throwaway894345 6y ago
I didn't pay much attention to the contracts proposal; is this just simpler because dynamic dispatch is vaguely similar to static dispatch, so it uses one syntax construct (interfaces) to denote both? I'm not opposed to this, but these aren't "interfaces" even though they use a similar syntax, notably the "constraining to a set of types" is supported for constraints and not interfaces. The thing I worry about the most is that Go without generics works very well for 95-99% of code. The code is very clear and not overly abstract. The remaining 1-5% of code is hard to write in an efficient, type safe, and DRY way, but I don't see how we can have generics and clear, appropriately-abstract code. I strongly suspect this will change the quality of the ecosystem for the worse. I don't think people consider this tradeoff very often.
- jasonwatkinspdx 6y ago
  > I don't think people consider this tradeoff very often. Every single time generics in go is discussed, a sizeable fraction of the comments are FUD about go inevitably turning into Boost. People consider the tradeoffs often, but in a superficial and dogmatic way based on language tribalism rather than actually looking at the proposal in detail and actually considering the tradeoffs.
  - throwaway894345 6y ago
    You've misunderstood the debate. The concern isn't about Go turning into Boost; it's about Go becoming multiparadigm--about losing the property that "all Go code tends to be written in the same general way" and that people will invariably write code that optimizes for abstraction instead of readability and utility as invariably happens in other languages. If you're not used to Go, you'll probably write this off very quickly because you underestimate (as we all did before we tried Go) how nice it is to have standard, appropriately-abstract code. This is why the debate inside the Go community is more nuanced and amicable--people understand the tradeoff better; they're not shouting uninformed opinions nor pretending there is no tradeoff or that the tradeoff is "just FUD" based on their utter inexperience.
    - cy_hauser 6y ago
      > about losing the property that "all Go code tends to be written in the same general way" I understand what you're saying but I think (hope?) you're going to be found wrong here. I think that: (1) very quickly "generic" code will come to be written in a fairly standard way that's accessible to any who cares to spend just a bit of time to know it. (2) there will be a lot less generic code than concerned Gophers think. I think the generic code will end up in libraries but not so much in application code. Except, of course, in code that uses generic libraries. But using generic code is much more understandable than writing it. Should be interesting to see how it all shakes out if this latest proposal passes muster. But I think Go will still be much more like "Go" rather than turning into what you dislike about other languages.
      - throwaway894345 6y ago
        I hope you’re right.
    - jasonwatkinspdx 6y ago
      This comes across as very patronizing. I've been using go for a couple years now. I'm very familiar with the detailed history of generics proposals in go. I disagree with your characterization and perspective, and continue to see it as simple FUD.
      - deleted 6y ago
        [deleted]
      - throwaway894345 6y ago
        If you were very familiar with the history, you would be well aware that virtually no one is expressing a concern about generics turning Go into Boost. That's a straw man of your own creation. You're welcome to see my characterization and perspective however you like.

throwaway894345 6y ago

I didn't pay much attention to the contracts proposal; is this just simpler because dynamic dispatch is vaguely similar to static dispatch, so it uses one syntax construct (interfaces) to denote both? I'm not opposed to this, but these aren't "interfaces" even though they use a similar syntax, notably the "constraining to a set of types" is supported for constraints and not interfaces. The thing I worry about the most is that Go without generics works very well for 95-99% of code. The code is very clear and not overly abstract. The remaining 1-5% of code is hard to write in an efficient, type safe, and DRY way, but I don't see how we can have generics and clear, appropriately-abstract code. I strongly suspect this will change the quality of the ecosystem for the worse. I don't think people consider this tradeoff very often.

jasonwatkinspdx 6y ago
> I don't think people consider this tradeoff very often. Every single time generics in go is discussed, a sizeable fraction of the comments are FUD about go inevitably turning into Boost. People consider the tradeoffs often, but in a superficial and dogmatic way based on language tribalism rather than actually looking at the proposal in detail and actually considering the tradeoffs.
- throwaway894345 6y ago
  You've misunderstood the debate. The concern isn't about Go turning into Boost; it's about Go becoming multiparadigm--about losing the property that "all Go code tends to be written in the same general way" and that people will invariably write code that optimizes for abstraction instead of readability and utility as invariably happens in other languages. If you're not used to Go, you'll probably write this off very quickly because you underestimate (as we all did before we tried Go) how nice it is to have standard, appropriately-abstract code. This is why the debate inside the Go community is more nuanced and amicable--people understand the tradeoff better; they're not shouting uninformed opinions nor pretending there is no tradeoff or that the tradeoff is "just FUD" based on their utter inexperience.
  - cy_hauser 6y ago
    > about losing the property that "all Go code tends to be written in the same general way" I understand what you're saying but I think (hope?) you're going to be found wrong here. I think that: (1) very quickly "generic" code will come to be written in a fairly standard way that's accessible to any who cares to spend just a bit of time to know it. (2) there will be a lot less generic code than concerned Gophers think. I think the generic code will end up in libraries but not so much in application code. Except, of course, in code that uses generic libraries. But using generic code is much more understandable than writing it. Should be interesting to see how it all shakes out if this latest proposal passes muster. But I think Go will still be much more like "Go" rather than turning into what you dislike about other languages.
    - throwaway894345 6y ago
      I hope you’re right.
  - jasonwatkinspdx 6y ago
    This comes across as very patronizing. I've been using go for a couple years now. I'm very familiar with the detailed history of generics proposals in go. I disagree with your characterization and perspective, and continue to see it as simple FUD.
    - deleted 6y ago
      [deleted]
    - throwaway894345 6y ago
      If you were very familiar with the history, you would be well aware that virtually no one is expressing a concern about generics turning Go into Boost. That's a straw man of your own creation. You're welcome to see my characterization and perspective however you like.