I'd say it's more a monolith vs microservices post than a Rails vs Go one. I tend to agree with the conclusion: microservices are a waste of time in many contexts.

That was my take away as well. It seems like the authors biggest mistake was choosing a very complex architecture, and the remedy was simplifying into a single service using a framework the author was more familiar with.

> It reached a point where I even split the application into five microservices (yep, I know), using HTTP for communication between them. Each service with its own mappers, models, and services folder.

Absent a need for asynchronous, independent access from multiple external web clients, I don't get why the author would want to do this. Isn't marshaling/unmarshaling always major infra overhead?

Why did the author start splitting his app into separate services?

I get using Ruby because you like Ruby. I like Clojure, and if I was building a new backend for ordinary web stuff, that’s probably what I’d gravitate to. But it sounds like Go was working til he got fancy with the architecture.

To me the conclusion is: he went back to the toolset he knows best, and that is Ruby on Rails; it has nothing to do with Golang.

Just because you don't know how to use Go toolset the right way, does not mean it's the wrong tool in general; but I understand your point(s).