[eru]

My speculation: the authors didn't know / understand algebraic data types.

Also, to make algebraic data types useful, you really want parametric polymorphism. But yet again, the others of Go weren't familiar with this. The only vaguely related technique they knew about were C++ templates, and they (reasonably!) decided that they didn't want C++ template hell in their language.

That last part about templates is the least speculative of the bunch: I read some of the discussion they had about generics, and they explicitly mentioned templates (and how complicated they are) and pretty much mentioned nothing else for how to design or implement generics.

Go recently got some generics, partially thanks to some help from Phil Wadler who's otherwise more known for his work in functional programming.

[wwalexander]

I think Wadler also helped out on Java generics.

[nextaccountic]

To make adts / sum types useful you really need pattern matching with destructuring, which Go appears to lack

https://kranfix.medium.com/pattern-matching-in-golang-195c73...

[eru]

You can use sum types without pattern matching and vice versa, but you are absolutely right that they synergies well.

I don't know enough about Golang: do you know whether it's possible to add pattern matching with destructuring as a fairly shallow syntactic sugar?

Generics were a much bigger change to the underlying language (and so would be Rust-like lifetimes, or even immutability); but pattern matching seems like something that should be relatively easy to add with only local repercussions?

[nextaccountic]

Yes, pattern matching (with destructuring) would be a small addition to the language, and it would be awesome, even without sum types

[eru]

Python had that kind of pattern matching for ages, but only recently got pattern matching on something like sum-types.

I only found that previous kind of pattern matching useful occasionally. But I guess I would miss it a lot, if it was gone?