To answer the question: what would a language look like if you put it's designers in a time capsule for 20+ years and had them make a language that was uninformed by all the language advances and learnings they'd missed out on.
It purposefully leaves out lots of features and cutting edge design philosophies because many Of those make things difficult when sharing code between multiple developers Spread over a long length of time.
Go’s philosophy has always been close to KISS. Don’t provide all these cutting edge tricks and tips because you can accomplish the same thing in a far clearer and maintainable way by doing it simpler.
Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect.
Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers for that matter), or creating constructs that make them much safer (such as what typescript is doing). Instead go doubles down on both of these. In the last decade of programming in kernel level c, python, ruby, c++, java, typescript, scala I've never worked with code that crashes so much and is as buggy as go.
Both of these problems could have been addressed fairly easily without bloating the language. Google has people on the c++ committee; it very much feels like the creators of go had too much hubris to walk down the hall or across the campus and kindly ask a good language designer to shoot holes in their design.
Another example is "iota". How does that make code sharing easy at scale? Any time I see iota, I have to start manually counting lines, and remember the rules for if blank lines or comments bump the counter, and it completely circumvents the ability to quickly grep for a value seen in a log message. It is completely antithetical to teams of people and spans of time and whatnot. It seems more like a team of three people who randomly had ideas and ran with them without thinking the consequences through very well, or consulting the wisdom of others.
That "billion dollar mistakes" is an excellent marketing expression (nobody wants to make billion-dollar mistakes! We should avoid that null they talk about! It looks so expensive!) but I don't know how actually true it is. Do we have any kind of scientific paper that proves languages without null lead to way less expensive software than languages with null?
I'm not talking about memory unsafe languages like C or C++, but situations where, in a memory-safe language, a null pointer exception in production happened to cost a shitload of money.
I'm pretty sure I never had a nil dereferencing in production with my go code. Invalid array access, off-by-one-errors, yeah, sure, way too many, but very few languages can prevent them at compile time. But nil dereferencing? I can't remember that.
Programming in Go is like trying to tie your shoes with one hand. You can do it, and its okay (I guess), but you can always see how things could be so much easier.
Maybe this is a bit much, but I find Go offensive: designed for the maximum amount of typing and least amount of thinking. Even Java looks like a powerful language in comparison.
They certainly got some things wrong (null for example, and errors aren't great, generic collections would be nice), but it's quite interesting just how much they left out while making a very usable (IMO) language.
I don't want advances and progress in a programming language, I want it to get out of the way and let me think.