I tend to view it more as a regressor. Golang is a conservative retrenchment towards Java pre-1.5 in a lot of ways. (And that may be fine for some use cases; I get the appeal even if I think it's misguided.)
Sure, there certainly is: it looks easy at first blush and scales moderately well. And that's fine, if you understand its drawbacks, and what Go aficionados try hard not to address is that Golang has a severe complexity wall. It is a large reason, along with faddish trendiness, why the Go universe clings so heavily to microservices: because the Golang is structured lends itself to writing messy code that is more easily combated by splitting into different systems rather than just writing modular code that respects encapsulation (in part because its type system is lousy, in part because error handling with deeply nested trees is harder than it needs to be, etc.). That this also creates additional problems--request tracing is an ongoing tire fire--is often elided a little bit, too.
In my experience, Go exhibits human-scaling problems long before even dynamically typed languages and significantly before Java, Kotlin, or the like. And the arguments to deployment are defanged both by Docker and by that it's usually not the developer who picks it who ends up building the CM around it in the first place (that's why they hire people like me, and why I have had to become uncomfortably familiar with Golang, its ecosystem, and the habits of your average Golang developer: because the person running the systems it runs on is inevitably the backstop for when those programs spit the bit).
But in the five-minute-demo-to-make-production-decisions universe, it plays really well.
