I think OP’s point is that given the go devs casual disregard for every development in PL theory and design over the last 30 years, it’s amusing to watch them rediscover half the issues from scratch.

This meme is commonly repeated on HN, but I think it's inaccurate or at least greatly exaggerated.

There's nothing casual about Go's approach to language design, and I haven't seen any evidence that they're unaware of what other languages do.

I also haven't seen much criticism of languages other than C++ or Java.

If they're aware of how other languages either handle these issues or suffer the consequences of not handling them, then it sure is odd that they consciously decided to introduce the same issues into their own language, only to fix them down the road.

Given Go’s success, it seems like fixing certain footguns much later actually worked out pretty well for them? That doesn’t necessarily mean it was right, but it was perhaps not as big a deal as some people assume.

Sum/Product types. Generics/type-parameters. Bizarre handling of nil in places. Error handling that’s like some deliberately crippled version of a Result<T,E>. The absolutely unhinged decision about zero-value-defaults for types. I’m sure other people can think of some more, but that’s the ones I can think of off the top of my head.

Non PL theory but related: incorrect implementation of monotonic clocks, and then refusing to fix it because “just use google smear time bro”.

Go definitely implements monotonic clocks correctly?

https://pkg.go.dev/time#hdr-Monotonic_Clocks

It definitely didn’t used to lol:

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Rather illustrative article, especially re the false simplicity where the language just silently does the wrong thing

(though I disagree that ".ext" is not an extension of an empty base name)

That article is so cringeworthy

I disagree, but the style isn’t for everyone.

However, that still doesn’t mean that it’s wrong.

Everyone who disagrees with you is “unhinged.” This is just name-calling.

But they’re like, genuinely wild decisions? Unhinged is a great description!

The error design can return the value, or an error, or both, for some inexplicable reason and you can check it - or not - and if your function returned some indication of severe error, and you happen to not check it, you can totes just continue your program, in who knows what invalid state. Oh and also, because the devs are apparently deathly allergic to abstractions of apparently kind, you’ve got to do this janky little if err != nil check at. every. single. point. Which occludes your fundamentally important logic in pointless line noise, with zero opportunity for streamlining or improving the logic or guarantees.

There's no need for compromise in this case. This issue is something I learned about in the late 90s / early 2000s when I started reading about programming language theory. It's found in introductory textbooks.