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.