[mappu]

I don't understand, why did you think Go "ignored" them?

I think a really important insight from ~50 years of PLs is that recent language features (say: lifetimes, or dependent types) do not always correlate with practical adoption, security guarantees, low cognitive overhead, teachability, readability, fast compilation, mechanical sympathy, and other such goals.

You can totally argue that Go should have been designed differently, but it's much harsher and untrue to say the designers ignored the ideas you have in mind.

[zaptheimpaler]

Go the language is simple at the expense of code written in Go being complex. That’s why it sucks. Every problem it doesn’t solve or solves poorly to eschew complexity is a problem every Go codebase now has its own bespoke pattern or hack or library to solve. Its low cognitive overhead is false economy.

[troupo]

You can't have "low cognitive overhead" and Go's "let's pollute every single line of code with error handling". Same for "let's have multiple versions of the same type everywhere because we don't have generics" (thankfully, fixed). And so on.

[tubthumper8]

"Ignoring" is the charitable framing of this.

Sum types and product types are fundamental to a type system, the same way that addition and multiplication are fundamental to arithmetic.

You wouldn't design a language with only multiplication and not addition. You wouldn't design boolean operations with only `&&` and not `||`. You wouldn't design bitwise operations with only `&` and not `^`. You wouldn't design set operations with only `∩` and not `∪`.

The alternative to "ignore" here is "ignorant", so it seems a nicer intention that they were aware of the fundamentals and chose not to use them.

[mappu]

Thanks for your input! All the design proposal RFCs have shown they cause an issue with the Go Compatibility Promise whereby adding any enum value can cause a semver-MAJOR breaking change. This causes a greater rate of ecosystem churn which, in every design proposal so far, has been deemed a net negative outweighing the modelling benefits.

[tubthumper8]

Yep, I'm aware. The question you asked was about the Go language designers ignoring the fundamentals, which is the root cause of this situation today where fundamentals can't be bolted on to the language later

[VirusNewbie]

Generics

[rob74]

Yes, generics. Have all the people complaining about the lack of generics in Go adopted it now that it supports generics? No, they found other things to complain about. So this should probably be a lesson to stop looking for the "next big thing" to implement (non-nullability? Union types?).

[troupo]

Yes, people will complain about other things. Why is it surprising to you?

Generics was a big thing because it impacted how a lot of code was written. It doesn't mean people don't want other things in the language that is hell bent on ignoring any practical advances in languages of the past 50 years.

What you propose is to basically stop improving the language because people complain.