If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful.
You want a scalable system that’s easy to write and will grow with you? Write basic Go services.
That makes no sense. It's very easy to build a REST API in Rails in which case you can connect to that API from services written in other languages. Conversely, you can easily call out to other services' APIs from Rails.
In fact, I'll go so far as to say building a few choice services in particularly performant (lower-level) languages alongside a main Rails monolith is the best organizational pattern for larger applications and enterprise deployments. You get all the benefits of Ruby & Rails for most happy paths, as well as the benefits of "This goes to 11!!!" performance for the critical paths which need that.
I've seen great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts.
After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches.
Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable.
These are all tools in the tool kit. Use what lets you ship.
This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev
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.
To go to your bosses and tell them you have to migrate from Ruby to Go to improve productivity is a blatant lie.
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 has better safeguards to prevent bad dev behavior
There shouldn't be any more tests, you're testing an API either way
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.
Maybe you're doing it wrong?
“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.
If you wrote a system in Go as a monolith, it would be hard to trim down, too. Architecture matters MUCH more than the implementation language.
Ruby/Rails' culture is a huge contributor to why Rails monoliths are so much more difficult to maintain compared to other dynamic languages. Things in Rubyland just love to be global and manipulate things globally and go out of their way to make that behavior hidden.
I question that assertion. I have plenty of anecdotes which are the exact opposite: a Rails monolith is much easier to maintain compared to similar approaches in other languages.
"manipulate things globally"
Not sure what you mean by that to be quite honest. If you mean monkey-patching, that's generally been frowned upon except at the framework-level in the Ruby community for quite a while now.
What's so easy about Go? I don't get it. Honestly. What's so hard for you to do in Ruby? And who's to say that in 15 years those shiny Go services you're working on won't become shit after dozens of changing devs had their way with them? Turning a codebase into shit takes time.
When i hear "Rails monolith is a disaster" what it usually boils down to 8 out of 10 times is people putting their business logic inside models or controllers, when really it should live in its own set of classes, usually called services or service objects.
Here's a guide https://codeclimate.com/blog/7-ways-to-decompose-fat-activer...
I ask this genuinely as I am interested to see what pain point people have with Rails.
a) they don't like Ruby for whatever reason, b) they probably only deal in backend or only deal in frontend, and so don't understand the value of the bundled dev experience rails delivers, and therefore c) because of a + b they find the moderate learning curve to be extra painful, so they lash out.
at the end of the day it's all just code. why would it be harder to integrate a service in Rails than in Go? of course it isn't.
1. Ruby is a very flexible language, and that has its ups and downs. While it makes it a very pleasurable easily modifiable syntax, it also leaves a lot of room for bad patterns. Ruby won't judge someone for taking an ill-advised approach to a problem, so it's easy for newcomers or novices to lay foundations that cause trouble later on.
2. Ruby is very prominent in startups, which are the companies most interested in immediate results. This often leads to favoring short-term advantages such as getting a feature out today to secure a deal rather than long-term advantages such as taking the time to keep a maintainable code base. Some startups with strict budgets will also hire people with less experience early on, leading this to pair with point 1 more often than we'd like.
That said, I'm a Ruby dev and have no interest in working in any other language (other than JS on the frontend). It's a beautiful tool to those who treat it well and I'll happily use it for just about any project.