Hacker News new | ask | show | jobs
by likortera 1510 days ago
I've been at a company that did this, they started migrating everything to Go because it was the new cool thing to do and everyone was in love with it.

One year later it was a mess of network calls, no ORMs and nearly-raw queries because who needs an ORM, migrations run by SQL statements on bash scripts because who needs migrations. Validations were custom wrappers on some validation libraries and validation errors were of course not consistent across all of the microservices, not because of lack of agreement, but because new ideas and ways to "do it better" showed up all the time.

Some of these "services" needed translations (for emails, hooks, and some html responses) so a custom "very simple" translation system was invented.

It became an infinite mesh of proxy services on top of proxy services on top of proxy services on top of kubernetes.... and at the end of the day, guess what was paying the bills? guess what still had all the business logic and was the source of truth?

The Rails application.

if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.

Do you know why it went everything that way? Because management decided that if they blocked people from using Go then people would leave the company. I was one of the managers there, and pretty opposed to this as you can notice.

But I think this is a huge reality around here. People want to play with new shiny, without even thinking of the drawbacks or if they do have a concurrency or raw cpu performance in their application.

People want to make a CV in what they want to use in their next job. And Rails is not fashionable anymore so "the monolith is bad" and "Go microservices" are good. You're not google 99% of the time.

Thankfully I left all that madness and now I'm in a more sane (although "not so cool" technologically) place where we focus on shipping product and keeping things maintainable, robust and secure.

3 comments

This is so true. Now there's ORM for Go (Gorm), and maybe a few web frameworks, but it just feels like any other beginning ecosystem - not much on Stackoverflow if you run into problems, docs aren't that good yet, incomplete APIs, missing functionality. And it has the same Node mindset of not having a major framework to tie everything together like Rails does- which I hate.

To go to your bosses and tell them you have to migrate from Ruby to Go to improve productivity is a blatant lie.

Well, the usual "reasoning" is that Go is easier to maintain, faster, will require less hardware, etc... all of those things might be true. What is not told in is the other side of the story, the one where you will have to write, test, document and maintain a TON more code... which usually ends up in just overall lower quality as it is pretty hard to find developers writing better code than the code you usually find in popular full stack frameworks.

But managers/directors, etc aren't idiots. They swallow it and they accept it even if they know the trade offs, because what's not told here is that if management says "No, that's madness" then people quit, and that's worse. So there we go with our super performant microservices for our 10 reqs/s app.

Go autodocuments really well

Go has better safeguards to prevent bad dev behavior

There shouldn't be any more tests, you're testing an API either way

We're not talking here about documenting apis.

We're talking about documenting an architecture, how pieces work together, what tools are available, where to put things, etc. Check the documentation of any major web framework. That's what we're talking about.

What do you mean there shouldn't be any more tests?
huh? Go has had ORMs for ages and they are fine
> One year later it was a mess of network calls, no ORMs and nearly-raw queries because who needs an ORM, migrations run by SQL statements on bash scripts because who needs migrations.

“Those who cannot remember the past are condemned to repeat it.” – George Santayana, The Life of Reason, 1905.

> if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Gosh I'm old.

Huh, well I've written lots of Go services and worked in lots of Go architectures and it was all worked really well actually. Looks a lot better than spaghetti code in a monolith

Maybe you're doing it wrong?

Maybe I'm not that interested in how nice it looks and more in how many people are necessary to maintain it and provide something useful to customers at a reasonable cost for my employer.