I've worked directly with hundreds of highly paid programmers over decades. I can count on my fingers the number that would be at all constrained by using Go where it's a suitable choice (an important caveat).
The rest would have their work highly improved by using Go as much as possible, precisely because it's harder to write bad code in Go compared with most languages.
I have worked in many, many codebases and I just can’t say I agree. There are some ways in which go programmers don’t write code as badly as they might have in other ecosystems, but there are plenty of other ways in which they’re actively encouraged to by the language.
And it’s not particularly maintainable. Yes, I can always “just read the code” to figure out what something is doing. But I often have to read more than five times the amount of code to understand what’s being accomplished. On top of that, due to the lack of abstraction power, I have to mentally decompile algorithmic implementations into the actual high-level task they’re actually performing. The (minor, but obvious and) classic example is having to mentally parse every single loop to determine if it’s a map, a reduce, filter, or something else.
Go is certainly more verbose than the more expressive languages but the code is also usually much more robust and reliable in my experience, due to strong types, error handling, the well tested standard library.
On your example, the for loop verbosity is a bit annoying and I'm happy that go 1.23 got user defined iterators to help with this https://tip.golang.org/doc/go1.23#iterators
The loop verbosity thing was just single obvious example and it's good that golang has finally gotten iterators (though their design is… weird IMO). But it's also only one of many, many issues underlying why go code is much more tedious to comprehend than code written in other HLLs.