Here's a document I've found that summarizes the discussion- I thought it was a really interesting read given my lack of background in language design - https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...
Why is there a need for features that you like from other languages?
I was referring to features that may be in various other languages and not wanting them in Go just because they were "liked from other languages." I want them in Go "because they make Go a better language."™
People can debate things like the complexity of compilers, parsers, etc. till the cows come home, but at the end of the day programming languages are just as much about the users as they are the actual code and specifications. Go succeeds not because it is perfect but because it has an ethos that resonates with its userbase. There is a “Go” way of writing things: flat happy path, handle every error explicitly in some way, using struct tags to hold metadata and schema information, and so on.
Meanwhile, most people who are talking about features in Go are really talking about two things: generics and exceptions/error handling. A lot of long time Go users don’t support many such proposals. And it’s not because either of those things are awful (although I don’t like exceptions.) In fact I like and use languages with either. Rust is great no doubt, although I can not claim to be an expert. All the same, Go does not need to be another Rust.
Why not generics/better metaprogramming? Because “it’s complicated.” Go takes different trade offs like using runtime reflection at the cost of CPU cycles and type safety. It works well in many cases. Generics complicated the language, of course, but moreso, it adds a new way of solving problems in an ecosystem that has already adapted to not having generics. All kinds of things may need to be re-imagined.
This is exactly why I like the Go contracts design: it offers a very limited solution to the problems that reflection do not solve so well, without a ton of implications for the remainder of the language.
Why not error handling? Of course, as usual, it adds complexity to the language/compiler/toolchain, but I also just don’t feel like there’s a problem. Go error handling is a little verbose, but its explicit and simple. Like many other things in Go, the resulting code looks dumb, but that’s what many of us like about Go. The code is dumb and simple.
And these are all features that are pretty well explored in other programming languages that are well-liked. I can’t imagine allowing too many additional features, which become part of the language and are probably stuck as such for compatibility reasons, without a real ton of research.