
Why Ruby on Rails Applications Should Consider Adding Go to Their Stack - dcu
https://sphereinc.com/why-ruby-on-rails-applications-should-consider-adding-go-to-their-stack/
======
1123581321
I don’t find this piece compelling. Go does offer performance benefits.
However, most web applications do not reach a state of maturity that justifies
a rewrite. The acknowledged initial development time advantage Ruby offers is
compounded into successive development cycles. SOA is not necessarily a good
architecture objective, and API structure arguably benefits more from Rails’
defaults than Go’s constrained syntax. Finally, more Rails developers
interested in improved concurrency programming would adopt Phoenix than would
adopt Go.

------
jarsin
"We have no clue what we are talking about. We just want to look smart for
clients who have no clue what we are talking about either, and hopefully get
some business."

------
hartator
> Rails won’t provide any boilerplate solutions in order to solve computer-
> science related problems.

Not sure what "computer-science" means in this instance.

------
meesterdude
Sorry, but this article makes no worthwhile argument for why RoR devs should
consider Go, it's just circle jerk.

> The main approach to resolve performance and stability issues in an
> established system, as well as team scalability problems, is to split the
> monolithic kernels into a set of microservices.

For one, this goes against the idea of having a monolith and all the benefits
that has. SOA trades one set of problems for another, and requires an
organizational and cognitive shift in approach.

> Go excels when projects get into phase when everything should be calm and
> steady.

So does Ruby? And also when it's not.

> you may want to think about adding Go into the stack to take care of the
> most complex code while the remaining Ruby/RoR stack provides an older but
> solid website engine

"older but solid". THat's a disingenuous attempt at calling rails obsolete or
legacy - neither of which, in any way, it is.

> Go is fresh

Oh I see where we're going with this now.

> it’s also important to think about what’s going to happen with the project
> in the next couple of years. Every technology that exists on the market has
> its own lifespan and a couple of target problem domains where it’d be the
> best solution to use.

Yes, you should be thinking of the long term - of the project you're building.
Go might very well be a good choice for your problem domain, but for most
startups they simply do not need it. Keeping everything in the same
stack/language makes it more portable between devs and easier to reason about.
When you start rolling up your sleeves and creating custom stuff like Go SOA;
you lose that and the complexity of the service amplifies. It also means you
now have to hire rails + Go devs.

Go is a lower level language. You have to write a lot to do the basics that,
in ruby/rails, are just a method call away. This is not a free trade off or
anywhere close to 1:1 on the productivity that this article claims. Yes, there
are benefits to Go and for certain types of work it does well. But for
literally 95% of the workloads out there, a set of background workers
executing jobs does perfectly well up to some very large scales.

on a personal note, what draws me to ruby/rails does not appear in Go. It's a
different language, different "culture" (or lack of), and different mindset on
work and what should & should not be. It's more.... google.

Anyway, Go is the right choice in some situations. But for most, just stick
with ruby on rails until you really start hitting growing pains. Shopify does
80K Requests PER SECOND on a rails stack.

