Great points. But I strongly disagree with “Code written in Go is easy to maintain”. In fact, IMO, Go code is among the most unmaintainable code. Here are my reasons:

1. The “type” of an object is ambiguous. To find out, you have to look through all the code to discover what methods it implements. I once had to reverse engineer the code of several Docker tools, and I wasted untold hours trying to find what methods things implemented and what types they could be.
2. One cannot find where things are defined. The name of a file has no relation to the things that are defined within it.
3. The kind of binding that it uses for the target of a method call is different from the way that it treats a parameter. How many programmers will be tripped up by that?
4. If you check something for nil, you might get true, but if you then do a type assertion on it and save the result, and check that for nil, you might get false! How many bugs will that create?!
5. Go tries to force you to keep all of your projects under one Go root. That is not how many people do things. Getting around that is troublesome.
6. It might have changed, but when I used Go (for about a year), its package mechanism was broken and the rules were poorly documented.
7. One cannot easily find answers by Googling: try googing “how to do a type assertion in Go” — the word “go” is an English language word. Of course, people sometimes post with the term “golang”, but not always, so you might miss the answers you seek.
8. The culture of the Go community seems to favor short variable names. Try reverse engineering someone else’s code, and searching for, say, where something called “pr” is defined — you will get hundreds of false matches.