Sum and intersection types + pattern matching feels so natural in languages like F#, OCaml, Reason, and Elixir. I know they add a significant amount of complexity to the language, but the more I use them, the more I feel that the tradeoff lands in the goldilocks "just right" zone. I find myself missing them often.

> feels so natural

Yes. They are as important as records/structs a.k.a. product types.

> F#, OCaml, Reason, and Elixir

Haskell, Elm, PureScript, Kotlin, Idris, ...

> I know they add a significant amount of complexity to the language

Really? I dont think it can be so much more than generics :)

Elm has 'm and the whole language is 5k lines of code.

How exactly are you going to implement a type safe option type without generics? You either have to use interface{}, which is obviously not type safe, or write/generate an option type for every type contained within it. Sum types are a lot less useful if you don't have generics.

It could have been built in to the language. Tons of builtin features (slices, maps, channels) are already "generic".

This

Yes. But null-safety is absolute on the top (as it is soooo hard, maybe even impossible, to add later).

Generics... Well, I just come from a Elm gig (knowing Haskell/C++/Java/Kotlin/Ruby) and I must say I was not too bothered with the lack of generics there.

Wait, doesn't Elm have parametric polymorphism like other ML-family languages? That's just as powerful as most languages' generics, and with a lot fewer brackets.

> Well, I just come from a Elm gig and I must say I was not too bothered with the lack of generics there.

Elm has generics.

Really? Why then there's List.map, Maybe.map, Array.map, and I have to select one of them? Is that not what generics would fix?

> Is that not what generics would fix?

No. That would be fixed by having something akin to typeclasses, traits or interfaces.

Elm's List, Maybe and Array are all defined using a generic type parameter.

No, it fixes that you don't have to chose between ListOfInts, ListOfStrings and ListOfListOfArrayOfInt.

BTW, one doesn't have to chose between them in Go either, but only because there are under-the-hood generics for the native types, that are only accessible to the language designers.

There is a terminology issue here, with "generic" being overloaded to mean different things. Parametric polymorphism is what Go is adding. You'd like to see something like ad hoc polymorphism in Elm, like type-classes in Haskell. But neither of those should be confused with the datatype generic programming.

https://en.wikipedia.org/wiki/Parametric_polymorphism

https://en.wikipedia.org/wiki/Ad_hoc_polymorphism

https://wiki.haskell.org/Generics

I think you want generics for many useful sum types (e.g. options) so you don't have to repeat your sum type definition everywhere it is used. Also, you can have options and matching without sum types (e.g. scala).

btw. scala 3 might change that. there is a language feature which can be turned on to have explicit nulls, which will be in the form of union/sum types: https://dotty.epfl.ch/docs/reference/other-new-features/expl...

Python has all of those things, including generics, so whatever order they are needed in, “Python got it” doesn't argue for one over the others.