I’ve dumped 18 years of C++ experience for Go in 2018, and never wanted to come back. Took me a couple of months to become accustomed.

The main Go’s feature is a green light for ignoring OOP baggage collected for decades, which makes writing code unnecessary burden. And Go have tools for not doing that.

Yes, sometimes it can be a bit ugly, but if you’re ready to trade academic impeccability for ease of use, it’s a real blast.

I’ve seen a lot of bad code in Go, which tried to do OOP things taught in school or books. Just don’t. Go requires a different approach, different mindset. Then everything falls in their places.

I was referring another comment in the thread, sorry for confusion. The OP attacks both Go and microservices, although it’s no Gos fault in the story.

Also I just hate Java too, and OOP in general.

According to votes, hating Java is bad, but hating microservices is good.

Well, that’s the architecture problem, not the language.

Swap Java and Go in text, then I buy it. Java is memory hungry monstrosity that runs on JVM and idiomatically uses piles of abstractions. I have exactly opposite experience, when rewriting a microservice from Java to Go reduced memory usage tenfold and sped up requests processing.

Hiding the complexity behind nice interfaces makes it actually more difficult to understand programming.

This is a very important point, that most of my colleagues with OOP background seem to miss. They build a bunch of abstractions and then say it’s easy, because we have one liner in calling code, pretending that the rest of the code doesn’t exist. Oh yes, it certainly exists! And needs to be maintained, too.

In Go, the recommended convention for variable name length is to be proportional to their scope. It is common to use one or few letters long variables if they are local to a few lines loop or a short function.

In Go you can compare structure instances with == (by value). You can also compare pointers (in which case they can be different even if values are equal). You get what you ask for.

Also, I’ve never needed “Equals” method in Go.