Why Generics?

Post by pvg » Wed, Jul 31, 2019, 9:29 PM UTC

grumdan wrote: post #104

iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

> because all existing implementations are bad I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial…

Post by shaded-enmity » Wed, Jul 31, 2019, 9:32 PM UTC

iainmerrick wrote: post #123

shaded-enmity wrote: post #114

Earlier quoted context omitted.

What is your point? Serious question. If you tell me, for example, that Go generics are going to be like C# generics, then I have to be familiar with the full semantics of C# generics. Essentially you tell me that in order to understand X I have to understand Y first, that's not good. Consumers of your language are not, for the MOST part, PLT nerds.

I’d compare it to e.g. the work on async/await in Rust, where the discussion seems more directly “we like this feature that C# pioneered and JS has adopted, here’s how we plan to adapt it to make it work well with Rust.” Admittedly, the Rust async/await RFC and the Go contracts proposal both discuss prior art in sections towards the end, so they are actually similar in that respect. Maybe it’s really just a question…

Post by baby » Wed, Jul 31, 2019, 9:34 PM UTC

theli0nheart wrote: post #106

fabiensanglard wrote: post #60

I hope this doesn't happen. I love golang because it is simple and easy to read. Both will go away when generic programmer start to write unreadable meta-programming class which "you don't need to understand, just use them". I admire golang devs for being opinionated and stand up for the core lines of their language so far. I see generic as renouncing these principles.

I don't think it's as clear-cut as you make it seem. Generics greatly reduce the amount of code we need to read in exchange an slight increase in abstraction. In my opinion, the tradeoff is worth it, especially given that Go already has abstractions that are more difficult to grok than generics, which, all things considered, aren't that hard to understand.

Post by gizmo686 » Wed, Jul 31, 2019, 9:37 PM UTC

grumdan wrote: post #104

iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

> because all existing implementations are bad I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial…

Post by haolez » Wed, Jul 31, 2019, 9:41 PM UTC

btilly wrote: post #37

haolez wrote: post #2

Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple. However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

Which interfaces-based solution? The one used by sort is a hack that only works for some of the things that you would want to do. The one where you use introspection performs badly and isn't typesafe. The tree implementation in the article cannot be done in a safe and performant way in Go today.