Go is awesome. Majority of go developers all like go for the same reasons: they are tired of feature-packed kitchensink languages, huge memory consumtions of JVM and onther xVM-s (I'm sorry cpython), slow execution times, and the abnormal complexity that projects seem to reach while using theese languages.
Go solved all theese problems, and it solved them in a fantastic and well thought way. Go is simply pure - after more than a year of coding in go, it's somewhat hard for me to write personal projects in languages that I used to do it before (Python, Java, even C lost a part of its charm for me ...).
However, what I'm seeing more and more often lately is big companies starting to use Go. It does make sense - Go is performance wise a better option than say C# or Java. But companies that transitioned to go AND are writing idiomatic go are rare. I can only think of Google and mabybe a few others. But the rest of the crowd is transitioning to Go and still writing same old incomprehensive and complicated code they used to write prior to the transition.
I think the key factor to blame is the fact that big companies like monolithic code since it fits their buerraucratic principles. And while Go can be used for monoliths, it doesn't like them much. When you write such code you start to write "hacky" and loose a sense of the sane programming patterns that Go wants to enforce on you. Go tries to make you break your codebase into managable moving parts. If you don't do it, both you and your code start to feel cluttered.
The biggest issue I've seen so far (from certain open sourced projects maintained by certain big corps) is that folks at big corps like to write Go like it is a object orineted language. Yes, there is a "oop-ish" way of coding in Go by defining methods on structs, but Go is an will always be a procedural language. That is when it shines the most. If you want a performant OOP language, go for C++ or something. You will lose on the clarity of the codebase, but you will not make Go sad by using it improperly.