Yyyyyeah, and I suppose if you ask BMW, remarkably, their electric vehicle would sound really good compared to Tesla which was good for niche uses.

Go is a pretty good language for lots of things, but for every area, something else is better.

Java has a bigger ecosystem. C++ is faster. Python is higher productivity. Erlang/Elixir have better parallelism. Lots of things have better abstraction capabilities to simplify the implementation of big projects.

The value of Go is that it's a decent compromise between all these things and fairly easy to learn to use (except it still drops the ball on abstraction--and I don't think the new generics really count because my read is that they don't solve enough of the abstraction problems and make learning considerably harder). It's as fast as Java, has an ecosystem big enough to cover almost all needs, is as productive as Kotlin (roughly, I'd guess), has good parallelism.

So, yeah, pretty reasonable choice.

But the choices aren't just between Rust and Go. Almost everything that eats Go's lunch can't touch Rust.

For example, why would you choose Go rather than a JVM stack with Kotlin or Scala? Go is easier to learn, yes (though Kotlin's not that hard), but performance is comparable, and the JVM has a more robust ecosystem. Pretty much the only use case where Go is clearly the right choice is "I want super-fast-starting command-line utilities". If you want iterop with Python, Go is certainly better than the JVM, but why not use Python plus a sprinkling of Rust? It will be both higher productivity (Python for most) and higher performance (Rust for the critical bits) in most cases.

Or you could just bite the bullet and go Rust all the way, utilizing a productivity-maximizing style that gives up a little performance by using copies and immutability and such to avoid most explicit lifetypes or multi-boxing, reasoning that compared to Go the possibly slower time to prototype (faster to prototype if generics would help simplify things substantially!) will be offset by the faster time to finish debugging. Discord wasn't all, "OMG it was SO HARD to learn Rust, and then when we did it took FOREVER to rewrite the Go stuff". No--instead it was, "Oh, this was pretty easy, and when we tried our first attempt it was...stupidly fast. Man. Why didn't we do this before?!" Furthermore, Go often makes you do simple but needless work--Discord actually complained that Go was making things harder: "It started as a rough translation, then we slimmed it down where it made sense. For instance, Rust has a great type system with extensive support for generics, so we could throw out Go code that existed simply due to lack of generics. Also, Rust’s memory model is able to reason about memory safety across threads, so we were able to throw away some of the manual cross-goroutine memory protection that was required in Go."

Francia also stated some things--like about Go being easier because you didn't have to tune for performance--that directly contradict reports in the wild. Discord again: "Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version." Uh, no knobs, Francia? Right.

So I think Francia's evaluation, while not entirely inaccurate is unreasonably favorable towards Go.

Go isn't a bad choice. (Well, unless you really like highly safe, broadly usable, domain-specialized code. People who love Haskell, Rust, or Scala may not wish to be subjected to Go.) You probably can solve most of your problems with it pretty well, without much effort getting into it. Not a very ringing endorsement, but given that very few other languages can make that rather middling pragmatic claim, it's hard to argue against. It's like a machete. Simple, easy to use, good for lots of stuff.

But it's also kind of hard to argue for.

It's more like, "Sure, why not?"