[ccktlmazeltov]

I really wish Go would pursue sum types instead of generics

[qtplatypus]

Sum types and Generics solve different but related problems. So they are not really comparable. I would like to see both get implemented.

[ccktlmazeltov]

I'd say it's really hard to abuse sum types, I wouldn't say the same of generics.

[qtplatypus]

That is true. However sum types don't allow us to abstract over common code. For example a sum type wouldn't allow us to create a type safe channel "fan in" function that works for all channel types.

[mrath]

Sum types without generics will still be good enough? I think for things like Option/Result we need both sum types and generics.

[ccktlmazeltov]

I don't think you would need user generics for this to work.

[OceanSpray]

Without generics, sum types would have to be a built-in like maps and arrays.

With generics, discriminated unions can take on all sorts of user-defined shapes.

[kccqzy]

Without generics, structs can take on all sorts of user-defined shapes. It's just that the types of its fields are fixed at declaration.

Without generics but with sum types, the sum types can still take on all sorts of user-defined shapes. It's just that the types of its various alternatives are fixed at declaration.

[masklinn]

Non-generic sum types are useful but you can’t build an option or result type out of them, so the usefulness is somewhat hampered.

[ccktlmazeltov]

But you don't need to, generic Option and Result types could be built as part of the standard library.

[masklinn]

Yes but then you need neither sum types nor user-defined generics, you can just build-in whatever sugar is useful or necessary (possibly repurposing existing sugar e.g. the `select` statement).

[ccktlmazeltov]

sum types are still super useful imo without generics.

[shp0ngle]

Aren't the new interfaces from the draft, where you can list bunch of possible types, sum types?

edit: oh. no.

https://go.googlesource.com/proposal/+/refs/heads/master/des...