3 ms·
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 yea
by likortera 4y 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.
- weatherlite 4y agoThis 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.
- likortera 4y agoWell, 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.
- mountainriver 4y agoGo 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
- likortera 4y agoWe'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.
- weatherlite 4y agoWhat do you mean there shouldn't be any more tests?
- mountainriver 4y agohuh? Go has had ORMs for ages and they are fine
- mountainriver 4y agoHuh, 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?
- likortera 4y agoMaybe 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.
- likortera 4y agoJust on time! https://news.ycombinator.com/item?id=31191700 https://news.ycombinator.com/item?id=31191700
- wainstead 4y ago> 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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Gosh I'm old.