It's really hard to take those arguments without a whole serving of salt because the things that it's ostensibly good at handling really aren't that much easier. Why is (un)marshalling data in a type safe way so damn hard in Go? Why does doing the same thing over and over and over and over never get easier? (Because the language lacks high level abstractions.

I used Go extensively at my last job and I was left feeling that there were pretty much always better choices. If you care about developer velocity with your more unskilled engineers, Go is a bad choice for a multitude of reasons. If you're going to need the performance over something else, the JVM is right there, and so too is Rust.

It's fair to just say "Well it's not for that" if you're not a general purpose language.

Like it sure is hard to write a grammar checker in WUFFS. Well, it's not for that, it's a special purpose language, it doesn't even have strings, stop trying to write a grammar checker.

For a general purpose language this is a poor excuse. I think the best argument might be a desire to avoid the Turing Tar-pit where everything is possible but nothing is easy. C++ allows you to write a type that's generic over the floating point values, so e.g. Foo<NaN>. What does that mean? Nothing useful. But they could so they did.

In avoiding the Turing Tar-pit you must make some choices which weren't necessary but were, in your opinion (as Benevolent dictator, Steering Committee, Riotous Assembly Of Interested People, or whatever) more aesthetic, more practical for some particular purpose you had in mind, easier to implement or whatever.

My impression with Go, which I spent a few years programming but never really loved, was that it's main value was in being surprisingly efficient for that type of language. Particularly startup of Go is good, which would matter for gojq for example.