3 ms·

> It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around t

by 4ad 5y ago

> It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to pay attention to. Yes, the mindset of the people was certainly a key part of this, but another key part is that Go has interfaces, which are existential types, which are dual to universal types (colloquially called generics). If the type system is expressive enough (System Fω), you can express one in terms of the other. Of course, Go's type system wasn't expressive enough to realize the true duality, but it was expressive enough to express many things people would have used generics for in other languages. Other languages which don't have generics don't have existential types either, and people see Go through that lens and don't understand how we got anything done. Well put on some existential glasses. As an aside, one of the reason it was so hard to develop a good design for generics is that they inevitably interact with interfaces, precisely because of the duality above. Unfortunately, the non-language experts who complained on web forums about the lack of generics in Go for the past 11 years do not understand what that means, but that didn't stop them from complaining. Let me put it another way. There's a reason why Rust traits are not types, but Go interfaces are types.

masklinn 5y ago
> Yes, the mindset of the people was certainly a key part of this, but another key part is that Go has interfaces, which are existential types, which are dual to universal types (colloquially called generics). The biggest reason was probably that it had bespoke generics for a bunch of core collections, significantly mitigating the need for userland generics. Without the builtin generic slice, map, and channel, the issue would have been significantly less tenable on both efficiency and convenience fronts. It's not like "we have interfaces and we still need generics" is a new thing.
- 4ad 5y ago
  This argument is often repeated but doesn't make any sense. The value of generics is quantifications over types. In particular univeral quantification. "Generic" slices don't give you that, because the values are "generic", but there are no non-static type constructors. Go slices are "generic" only in the same sense than arrays in C are generic, or (if we go to the degenerate case) that a variable is "generic" because you can declare it with any type. I'm sorry, what? Go has existential quantification, something which C lacks. Go is very unusual that it started with existential types. Languages based on System Fω have universal quantification as a native operation and implement existential types as higher rank universals. The fact that Go had existentials from the beggining is not some technical nitpick, it is what gives it type-level expressive power over languages like C. Ignoring this in arguments about generics is missing the point completely.

by 4ad 5y ago

masklinn 5y ago

> Yes, the mindset of the people was certainly a key part of this, but another key part is that Go has interfaces, which are existential types, which are dual to universal types (colloquially called generics). The biggest reason was probably that it had bespoke generics for a bunch of core collections, significantly mitigating the need for userland generics. Without the builtin generic slice, map, and channel, the issue would have been significantly less tenable on both efficiency and convenience fronts. It's not like "we have interfaces and we still need generics" is a new thing.

4ad 5y ago
This argument is often repeated but doesn't make any sense. The value of generics is quantifications over types. In particular univeral quantification. "Generic" slices don't give you that, because the values are "generic", but there are no non-static type constructors. Go slices are "generic" only in the same sense than arrays in C are generic, or (if we go to the degenerate case) that a variable is "generic" because you can declare it with any type. I'm sorry, what? Go has existential quantification, something which C lacks. Go is very unusual that it started with existential types. Languages based on System Fω have universal quantification as a native operation and implement existential types as higher rank universals. The fact that Go had existentials from the beggining is not some technical nitpick, it is what gives it type-level expressive power over languages like C. Ignoring this in arguments about generics is missing the point completely.