5 ms·

> The most obvious use for it is heterogenous containers. You mean runtime generic container without the benefits of compile-time type checking, opening the de

> The most obvious use for it is heterogenous containers. You mean runtime generic container without the benefits of compile-time type checking, opening the developer to runtime type errors purely for ideological reasons...

a1369209993 5y ago
> opening the developer to runtime type errors purely for ideological reasons... To be fair, there are also language-implementor-laziness reasons.
earthboundkid 5y ago
That Go would benefit from generics doesn't change the fact that there are also lots of use for heterogenous containers. As it is, Go already has "slices" for type safe containers. The fair complaint about Go is it's hard to do other type safe container than the built in "slice" and "map" containers. But the problem is on track to be fixed next year, so it's silly to complain about it now.
earthboundkid 5y ago
That Go would benefit from generics doesn't change the fact that there are also lots of use for heterogenous containers. As it is, Go already has "slices" for type safe containers. The fair complaint about Go is it's hard to do other type safe container than the built in "slice" and "map" containers. But the problem is on track to be fixed next year, so it's silly to complain about it now. It's really hard to take people who complain about Go seriously when they're pretty obviously just zealots who don't know much about the language besides "types good" and "Go bad". My stance: types good in moderation; Go a useful tradeoff of engineering attributes.
- throw_m239339 5y ago
  > so it's silly to complain about it now. No it isn't, Go has other flaws stemming from the exact same root cause and it has nothing to do with programming...
tptacek 5y ago
I think you read my comment as an invitation to debate dynamic vs. static safety checking. That seems like a deeply uninteresting debate. I'm just saying, there's a clear purpose to `interface{}`, and the same pattern shows up (though obviously much less frequently) in Rust.
- tomjakubowski 5y ago
  In the interest of supplying information to the curious, the Rust equivalent is to use an Any trait object with down casting. https://doc.rust-lang.org/std/any/index.html https://doc.rust-lang.org/std/any/index.html
jjnoakes 5y ago
The two are orthogonal. Even with generics, languages can have an "escape" type like interface{} which is used/necessary for when you do want (or require) run-time type checking.
mseepgood 5y ago
> 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?

a1369209993 5y ago

> opening the developer to runtime type errors purely for ideological reasons... To be fair, there are also language-implementor-laziness reasons.

earthboundkid 5y ago

That Go would benefit from generics doesn't change the fact that there are also lots of use for heterogenous containers. As it is, Go already has "slices" for type safe containers. The fair complaint about Go is it's hard to do other type safe container than the built in "slice" and "map" containers. But the problem is on track to be fixed next year, so it's silly to complain about it now. It's really hard to take people who complain about Go seriously when they're pretty obviously just zealots who don't know much about the language besides "types good" and "Go bad". My stance: types good in moderation; Go a useful tradeoff of engineering attributes.

throw_m239339 5y ago
> so it's silly to complain about it now. No it isn't, Go has other flaws stemming from the exact same root cause and it has nothing to do with programming...

tptacek 5y ago

I think you read my comment as an invitation to debate dynamic vs. static safety checking. That seems like a deeply uninteresting debate. I'm just saying, there's a clear purpose to `interface{}`, and the same pattern shows up (though obviously much less frequently) in Rust.

tomjakubowski 5y ago
In the interest of supplying information to the curious, the Rust equivalent is to use an Any trait object with down casting. https://doc.rust-lang.org/std/any/index.html https://doc.rust-lang.org/std/any/index.html

jjnoakes 5y ago

The two are orthogonal. Even with generics, languages can have an "escape" type like interface{} which is used/necessary for when you do want (or require) run-time type checking.

mseepgood 5y ago

> 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?