4 ms·

You aren't going to see any radical changes to the language in the 1.x series.

vanderZwan 14y ago
To explain that a bit further: the core Go team is not against generics by definition, they just believe that no generics is better than bad generics (where "bad" admittedly is subjective, but see Russ Cox' article on the topic[1]). If/when they find a solution that fits their strict criteria, it in all likelihood will require breaking changes to the Go language, and the point of having the 1.x series was a promise that this would not happen. [1] http://research.swtch.com/generic http://research.swtch.com/generic
- happy_dino 14y ago
  I'm wondering how long it will take until people will either stop linking to blatantly false articles or start reading more than the first 5 paragraphs of it.
  - vanderZwan 14y ago
    Apologies, I quickly Googled and pasted the link like you implied I did. I remember a longer, more deeply reasoned article than this one, and by quickly skimming I mistook this for that - it probably was somewhere on the go-nuts mailing list. The problem is that the topic of generics has come up so many times on that mailing list it will require quite a bit of digging to find that again. That said, the discussion below the article does get across the standpoint of the Go developers on the topic, doesn't it?
    - happy_dino 14y ago
      Sadly, the mailing list debates often don't contain much more than linking to this article and repeating unsubstantiated claims. The points brought up in the comment section below the article were not answered at all. Russ Cox: “I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes [...]” First comment: “How about C# implementation? It lets you use primitive types.” Second comment: “The massive gaping hole in your list of approaches is .NET: reified generics, but in a reference-type oriented language. [...]” Third comment: “http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx talks about the .Net Generic implementation in a bit more detail.” Russ Cox: ⁎crickets⁎
      - pjmlp 14y ago
        That is a common reaction, see this Plan9 response to a user that wanted more functionality out from ACME. http://9fans.net/archive/2008/08/134 http://9fans.net/archive/2008/08/134
        mseepgood 14y ago
        The user didn't ask for more functionality, he asked what the ACME way is.
      - mseepgood 14y ago
        I don't see how this solves the generics dilemma. From the MSDN article: "If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code. However, the JIT compiler keeps track of type-specific server code it already generated. If the JIT compiler is asked to compile the generic server with a value type it has already compiled to machine code, it simply returns a reference to that server code. Because the JIT compiler uses the same value-type-specific server code in all further encounters, there is no code bloating." So .NET has chosen number 2 with duplicate elimination: "This slows compilation. It generates a lot of code, much of it redundant, and needs a good linker to eliminate duplicate copies. The individual specializations may be efficient but the program as a whole can suffer due to poor use of the instruction cache."
        happy_dino 14y ago
        That's pretty much wrong on all accounts. I recommend getting a basic grasp of the topic before trying to defend Go in such an awkward way.
        vanderZwan 14y ago
        I have no idea whether you or the person you responded to is right (note that my earlier comment just stated the Go developer stance without any value judgement of my own), but please let's not allow ad hominems to muddy the discussion!

To explain that a bit further: the core Go team is not against generics by definition, they just believe that no generics is better than bad generics (where "bad" admittedly is subjective, but see Russ Cox' article on the topic[1]). If/when they find a solution that fits their strict criteria, it in all likelihood will require breaking changes to the Go language, and the point of having the 1.x series was a promise that this would not happen. [1] http://research.swtch.com/generic http://research.swtch.com/generic

happy_dino 14y ago
I'm wondering how long it will take until people will either stop linking to blatantly false articles or start reading more than the first 5 paragraphs of it.
- vanderZwan 14y ago
  Apologies, I quickly Googled and pasted the link like you implied I did. I remember a longer, more deeply reasoned article than this one, and by quickly skimming I mistook this for that - it probably was somewhere on the go-nuts mailing list. The problem is that the topic of generics has come up so many times on that mailing list it will require quite a bit of digging to find that again. That said, the discussion below the article does get across the standpoint of the Go developers on the topic, doesn't it?
  - happy_dino 14y ago
    Sadly, the mailing list debates often don't contain much more than linking to this article and repeating unsubstantiated claims. The points brought up in the comment section below the article were not answered at all. Russ Cox: “I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes [...]” First comment: “How about C# implementation? It lets you use primitive types.” Second comment: “The massive gaping hole in your list of approaches is .NET: reified generics, but in a reference-type oriented language. [...]” Third comment: “http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx talks about the .Net Generic implementation in a bit more detail.” Russ Cox: ⁎crickets⁎
    - pjmlp 14y ago
      That is a common reaction, see this Plan9 response to a user that wanted more functionality out from ACME. http://9fans.net/archive/2008/08/134 http://9fans.net/archive/2008/08/134
      - mseepgood 14y ago
        The user didn't ask for more functionality, he asked what the ACME way is.
    - mseepgood 14y ago
      I don't see how this solves the generics dilemma. From the MSDN article: "If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code. However, the JIT compiler keeps track of type-specific server code it already generated. If the JIT compiler is asked to compile the generic server with a value type it has already compiled to machine code, it simply returns a reference to that server code. Because the JIT compiler uses the same value-type-specific server code in all further encounters, there is no code bloating." So .NET has chosen number 2 with duplicate elimination: "This slows compilation. It generates a lot of code, much of it redundant, and needs a good linker to eliminate duplicate copies. The individual specializations may be efficient but the program as a whole can suffer due to poor use of the instruction cache."
      - happy_dino 14y ago
        That's pretty much wrong on all accounts. I recommend getting a basic grasp of the topic before trying to defend Go in such an awkward way.
        vanderZwan 14y ago
        I have no idea whether you or the person you responded to is right (note that my earlier comment just stated the Go developer stance without any value judgement of my own), but please let's not allow ad hominems to muddy the discussion!