https://curlang.org is a langauge that comes from go but is logical and unifies. Recursion is about to be removed from the language. It's real interesting both as a project and in theory

But with no practical experience in using these features, it’s basically impossible to know anything about how they would work and whether it would lead to Go being a better language. If they did not have a positive experience with these features in other languages, and also have good reason to believe it would port over and be a good impedance match for the language and community, there’s a lot of ground work to be done.

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.