4 ms·

But that is so rarely an issue... You might encounter an occasional specific circumstance where you will need do some code duplication in Go, but I've written m

But that is so rarely an issue... You might encounter an occasional specific circumstance where you will need do some code duplication in Go, but I've written many thousands of lines of Go and have had to resort to duplicated code once (and in that particular case all that required was a couple copy-pastes and minor edits, and I'd have to go back and revisit it but it's possible I could have solved it more elegantly if I'd known Go better).

danieldk 12y ago
But that is so rarely an issue... For you... It depends on what kind of code you are working on. If you work a lot on numeric code (e.g. in machine learning), you want to make it easy to specialize on e.g. 32-bit or 64-bit floats. Also, since only built-in types are generic, you cannot implement other containers (you never need binary search trees?) in a safe manner. So, yes, the lack of generics is a frequent issue for me.
- WaltPurvis 12y ago
  Yes, and that does not conflict with what I was saying. There are specific problem domains where generics would simplify matters, but in the overall universe of problems those domains are rare, i.e., most of the code that most programmers will write in Go will not involve duplicating code because of the absence of generics.
  - tree_of_item 12y ago
    I think you slipped in a subtle but annoying mistruth here: "in the overall universe of problems those domains are rare" is just not true. What is true is that the kinds of programs Go programmers typically write may end up not needing this sort of polymorphism, which is very different from saying "domains where this sort of polymorphism is important are rare". I only point this out because I've seen a lot of Go programmers defend Go by saying parametric polymorphism is only really important in particular niche domains, when really they want to say that Go only focuses on a particular niche domain where it isn't important.
  - GFK_of_xmaspast 12y ago
    I can't remember the last non-trivial c++ program I wrote that I didn't use generic containers like std::vector or std::unordered_set, or the last java program where I didn't use List.

danieldk 12y ago

But that is so rarely an issue... For you... It depends on what kind of code you are working on. If you work a lot on numeric code (e.g. in machine learning), you want to make it easy to specialize on e.g. 32-bit or 64-bit floats. Also, since only built-in types are generic, you cannot implement other containers (you never need binary search trees?) in a safe manner. So, yes, the lack of generics is a frequent issue for me.

WaltPurvis 12y ago
Yes, and that does not conflict with what I was saying. There are specific problem domains where generics would simplify matters, but in the overall universe of problems those domains are rare, i.e., most of the code that most programmers will write in Go will not involve duplicating code because of the absence of generics.
- tree_of_item 12y ago
  I think you slipped in a subtle but annoying mistruth here: "in the overall universe of problems those domains are rare" is just not true. What is true is that the kinds of programs Go programmers typically write may end up not needing this sort of polymorphism, which is very different from saying "domains where this sort of polymorphism is important are rare". I only point this out because I've seen a lot of Go programmers defend Go by saying parametric polymorphism is only really important in particular niche domains, when really they want to say that Go only focuses on a particular niche domain where it isn't important.
- GFK_of_xmaspast 12y ago
  I can't remember the last non-trivial c++ program I wrote that I didn't use generic containers like std::vector or std::unordered_set, or the last java program where I didn't use List.