4 ms·

> purely for ideological reasons There are no ideological reasons. https://github.com/golang/go/commit/dd64f86e0874804d0ec5b7138dafc28b51f61c12#diff-07f0a0a43

> purely for ideological reasons There are no ideological reasons. https://github.com/golang/go/commit/dd64f86e0874804d0ec5b7138dafc28b51f61c12#diff-07f0a0a43f65e50feb2abc7d6efbe3f8699de61509918c23260009490ba6ecbaR173 https://github.com/golang/go/commit/dd64f86e0874804d0ec5b713... "Generics may well come at some point." https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics "A language proposal implementing a form of generic types has been accepted for inclusion in the language. If all goes well it will be available in the Go 1.18 release." One of the language designers explaining the motivation for adding parametric polymorphism to Go: https://www.youtube.com/watch?v=RIvL2ONhFBI&t=1064s https://www.youtube.com/watch?v=RIvL2ONhFBI&t=1064s Explaining the benefits of generics: https://www.reddit.com/r/golang/comments/jditu9/what_do_generics_allow/g9a6a74?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/golang/comments/jditu9/what_do_gene... From the Featherweight Go paper: https://arxiv.org/pdf/2005.11710.pdf https://arxiv.org/pdf/2005.11710.pdf "Recently, the Go team mooted a design to extend Go with generics, and Rob Pike wrote Wadler to ask: Would you be interested in helping us get polymorphism right (and/or figuring out what “right” means) for some future version of Go?"

ibraheemdev 5y ago
Yup, it's a common misconception that Go language designers are anti-generics. They wanted to include generics, the reason they were left out is that there was no clear way to include them without significant downsides: > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times? > I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes, especially if there were good written descriptions (papers, blog posts, etc.) about what was hard and why it's a good approach. I'd also be interested to see good written descriptions of trying one of those approaches and what went wrong (or right). - Russ Cox (2009): https://research.swtch.com/generic https://research.swtch.com/generic
- paulddraper 5y ago
  > do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Which one did Rust choose?
  - mseepgood 5y ago
    slow compiler

ibraheemdev 5y ago

Yup, it's a common misconception that Go language designers are anti-generics. They wanted to include generics, the reason they were left out is that there was no clear way to include them without significant downsides: > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times? > I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes, especially if there were good written descriptions (papers, blog posts, etc.) about what was hard and why it's a good approach. I'd also be interested to see good written descriptions of trying one of those approaches and what went wrong (or right). - Russ Cox (2009): https://research.swtch.com/generic https://research.swtch.com/generic

paulddraper 5y ago
> do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Which one did Rust choose?
- mseepgood 5y ago
  slow compiler