5 ms·

I think this is one of the really great things about Go. Some detractors ask "There is so much to be gained by having generics! What would be lost if Go had gen

I think this is one of the really great things about Go. Some detractors ask "There is so much to be gained by having generics! What would be lost if Go had generics? Nothing! Ergo, Go is wrong to not have generics". This line of argument is flawed. Go curbs the ability of people to write crazy (and ultimately mentally expensive) abstractions. The lack of generics in Go is very a good thing. Especially when it comes to collaborating on a large unfamiliar code base. I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them. If there isn't, maybe I'm trying to solve the wrong problem, or it is the wrong language for the task.

MichaelGG 13y ago
Really? I thought the reason Go didn't have generics is because they couldn't decide on an implementation that met their goals? That is, was quick and didn't emit a ton of code.
- peterwaller 13y ago
  I don't claim that was their goal. I think it's just a nice side-effect.
  - aodin 13y ago
    Russ Cox, one of programmers working on Go, described the dilemma as: "do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" He expanded on this dilemma with examples from major languages: http://research.swtch.com/generic http://research.swtch.com/generic
    - masklinn 13y ago
      > He expanded on this dilemma with examples from major languages: http://research.swtch.com/generic http://research.swtch.com/generic My god, this is such completely dishonest bullshit strawman I'm impressed he had the balls to post that garbage. Java's boxing does not come from its generics, it's the other way around (java's non-Array collections have never been able to hold unboxed values), and C++'s template are pretty much unique in their complexity (and definitely not what PL people think about when talking about generics) and compounded by all the rest of C++'s baggage (D has C++-style templates and is nowhere as slow to compile). And his reaction to comments (that is, his complete failure to acknowledge how huge a strawman his original post is, and complete absence of response to any mention of C#, Eiffel, Ada, Haskell, MLs and others)... that is supposed to be a defense of goteam's thought process?
      - papsosouid 13y ago
        Unfortunately, that is their thought process. I find it hard to believe Rob, Russ, etc actually genuinely have never heard of ML, but everything they ever say on the issue suggests that is the case. And when people keep showing them "hey look, this problem was solved 30 years ago!" they just outright ignore them and don't acknowledge it.
      - mkehrt 13y ago
        I'm super pro generics and love me some Haskell and ML. However, generics really do have a cost. Since the size of the objects in a generic container can vary, you either need to take the ML route of making everything a pointer (which add runtime cost) or the C++ (yeah, not really generics, but still) route of duplicating the code for every size object you store in the container. While I think Go made the wrong choice with generics, I understand their thought process.
        quatrevingts 13y ago
        I'm curious what the cost would be of implementing generics by having an (implicit) parameter for the element size. It would certainly be a bit slower than the fully specialized version, but it avoids boxing and doesn't duplicate code.
tome 13y ago
Limiting power was the argument for making Java crippled too. On the topic of generics specifically, parametric polymorphism actually makes code simpler, see e.g. Haskell.
- peterwaller 13y ago
  I have to say, I love some of the principles of Haskell. I am a novice though and I currently don't stand a chance of picking up and hacking on a project without serious amount studying. However, with a cursory glance at Go, I was able to be productive in it and hack on the go compiler and runtime itself. Maybe this is more a statement about how little I know about functional languages or some of the theoretical techniques used in Haskell. Whilst my mortal brain comes to grips with Haskell I am being quite productive in Go. I have learned a lot on the way, too.
- koenigdavidmj 13y ago
  Whether by design or accident, Go is filling the use case of "you tried Python but performance wasn't good enough". People will bring up cases like "you can't write a generic map function, or tree data structures!", but Go isn't the language for those things. In Go, you would just use a for loop or a dictionary-based map. If your program gets to the point where that no longer cuts it, then it's time to move on to a different language.
  - JulianMorrison 13y ago
    …or a data structure that uses interface{} and you manually unpack. Or a hand specialized (rather than generic) data structure. Bear in mind that with the new release of Go, maps are already hand specialized for primitives.
  - deleted 13y ago
    [deleted]
  - deleted 13y ago
    [deleted]
  - azth 13y ago
cwzwarich 13y ago
If anything, generics reduce the mental expense of reading code, because if a container has a generic value type I know that it isn't going to be doing something interesting to those values behind the scenes.
- gohrt 13y ago
  That's only true in a language with type inference and type aliases. In Java, generics make your code completely unreadable, as content is buried in boilerplate. Map<Converter<Comment,Post>,ReadyState<CommentEnum> ops; for (Entry<Converter<Comment,Post>,ReadyState<CommentEnum> e: ops.entrySet()) { ... In Go, generics would be an unqualified win for the author/reader. No one disputes that. The only dispute is over the compiler and runtime costs.
  - masklinn 13y ago
    Generics (outside of C++'s templates which are a pretty odd duck[1]) generate very little compiler costs and little to no runtime costs (depending whether they're erased or reified), unless you decide to (optionally) trade some added compiler costs for some runtime improvements by generating type-specialized collections behind the scenes. [1] and their cost is seriously compounded by the rest of C++, D has C++-style generics with a far lower compilation cost
    - comex 13y ago
      Depends what you're comparing against. If it's a poor man's generic implementation in current Go using interface{}, then obviously there would be no extra runtime overhead if the compiler generated that for you in a type safe manner; but compared to manually specialized collections or the built-in generic collections, there is quite a lot of runtime overhead. Whether the compiler costs are manageable or not is up for debate.
      - masklinn 13y ago
        The built-in collections can remain built-in if that gets you off. Same deal for manually specialized collections, except those aren't generic, so they remain not generic.
papsosouid 13y ago
>This line of argument is flawed I don't think you intended that as a preface to your flawed argument, but it worked out well. No, the lack of parametric polymorphism is not a good thing. You are losing simplicity, not gaining it.
coldtea 13y ago
>I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them. Yes there is. Involving more code, less DRY, or loss of type safety.

MichaelGG 13y ago

Really? I thought the reason Go didn't have generics is because they couldn't decide on an implementation that met their goals? That is, was quick and didn't emit a ton of code.

peterwaller 13y ago
I don't claim that was their goal. I think it's just a nice side-effect.
- aodin 13y ago
  Russ Cox, one of programmers working on Go, described the dilemma as: "do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" He expanded on this dilemma with examples from major languages: http://research.swtch.com/generic http://research.swtch.com/generic
  - masklinn 13y ago
    > He expanded on this dilemma with examples from major languages: http://research.swtch.com/generic http://research.swtch.com/generic My god, this is such completely dishonest bullshit strawman I'm impressed he had the balls to post that garbage. Java's boxing does not come from its generics, it's the other way around (java's non-Array collections have never been able to hold unboxed values), and C++'s template are pretty much unique in their complexity (and definitely not what PL people think about when talking about generics) and compounded by all the rest of C++'s baggage (D has C++-style templates and is nowhere as slow to compile). And his reaction to comments (that is, his complete failure to acknowledge how huge a strawman his original post is, and complete absence of response to any mention of C#, Eiffel, Ada, Haskell, MLs and others)... that is supposed to be a defense of goteam's thought process?
    - papsosouid 13y ago
      Unfortunately, that is their thought process. I find it hard to believe Rob, Russ, etc actually genuinely have never heard of ML, but everything they ever say on the issue suggests that is the case. And when people keep showing them "hey look, this problem was solved 30 years ago!" they just outright ignore them and don't acknowledge it.
    - mkehrt 13y ago
      I'm super pro generics and love me some Haskell and ML. However, generics really do have a cost. Since the size of the objects in a generic container can vary, you either need to take the ML route of making everything a pointer (which add runtime cost) or the C++ (yeah, not really generics, but still) route of duplicating the code for every size object you store in the container. While I think Go made the wrong choice with generics, I understand their thought process.
      - quatrevingts 13y ago
        I'm curious what the cost would be of implementing generics by having an (implicit) parameter for the element size. It would certainly be a bit slower than the fully specialized version, but it avoids boxing and doesn't duplicate code.

tome 13y ago

Limiting power was the argument for making Java crippled too. On the topic of generics specifically, parametric polymorphism actually makes code simpler, see e.g. Haskell.

peterwaller 13y ago
I have to say, I love some of the principles of Haskell. I am a novice though and I currently don't stand a chance of picking up and hacking on a project without serious amount studying. However, with a cursory glance at Go, I was able to be productive in it and hack on the go compiler and runtime itself. Maybe this is more a statement about how little I know about functional languages or some of the theoretical techniques used in Haskell. Whilst my mortal brain comes to grips with Haskell I am being quite productive in Go. I have learned a lot on the way, too.
koenigdavidmj 13y ago
Whether by design or accident, Go is filling the use case of "you tried Python but performance wasn't good enough". People will bring up cases like "you can't write a generic map function, or tree data structures!", but Go isn't the language for those things. In Go, you would just use a for loop or a dictionary-based map. If your program gets to the point where that no longer cuts it, then it's time to move on to a different language.
- JulianMorrison 13y ago
  …or a data structure that uses interface{} and you manually unpack. Or a hand specialized (rather than generic) data structure. Bear in mind that with the new release of Go, maps are already hand specialized for primitives.
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
- azth 13y ago

cwzwarich 13y ago

If anything, generics reduce the mental expense of reading code, because if a container has a generic value type I know that it isn't going to be doing something interesting to those values behind the scenes.

gohrt 13y ago
That's only true in a language with type inference and type aliases. In Java, generics make your code completely unreadable, as content is buried in boilerplate. Map<Converter<Comment,Post>,ReadyState<CommentEnum> ops; for (Entry<Converter<Comment,Post>,ReadyState<CommentEnum> e: ops.entrySet()) { ... In Go, generics would be an unqualified win for the author/reader. No one disputes that. The only dispute is over the compiler and runtime costs.
- masklinn 13y ago
  Generics (outside of C++'s templates which are a pretty odd duck[1]) generate very little compiler costs and little to no runtime costs (depending whether they're erased or reified), unless you decide to (optionally) trade some added compiler costs for some runtime improvements by generating type-specialized collections behind the scenes. [1] and their cost is seriously compounded by the rest of C++, D has C++-style generics with a far lower compilation cost
  - comex 13y ago
    Depends what you're comparing against. If it's a poor man's generic implementation in current Go using interface{}, then obviously there would be no extra runtime overhead if the compiler generated that for you in a type safe manner; but compared to manually specialized collections or the built-in generic collections, there is quite a lot of runtime overhead. Whether the compiler costs are manageable or not is up for debate.
    - masklinn 13y ago
      The built-in collections can remain built-in if that gets you off. Same deal for manually specialized collections, except those aren't generic, so they remain not generic.

papsosouid 13y ago

>This line of argument is flawed I don't think you intended that as a preface to your flawed argument, but it worked out well. No, the lack of parametric polymorphism is not a good thing. You are losing simplicity, not gaining it.

coldtea 13y ago

>I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them. Yes there is. Involving more code, less DRY, or loss of type safety.