[ericskiff]

We're still starting new greenfield projects in Rails every week, and I still believe it's the best foundation for SaaS products. It's great for developer speed and efficiency, the ecosystem of gems is amazing, and we've been able to scale every project we've needed to. We're incorporating React and GraphQL more these days for complex components and APIs but they pair nicely with Rails.

[mountainriver]

I work at a company with a large Ruby monolith and it’s a disaster.

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.

[jaredcwhite]

"trying to build services alongside it is truly awful"

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.

[mountainriver]

Yup its just that everyone else needs to learn the spaghetti code in the monolith. Which is universally hated by everyone not in the rails ecosystem

[boboroshi]

Monoliths can be great or a disaster, as can total services setups. We took a monolith built by a small team into scores of services across 4 teams of 150 engineers, even implementing some of them in Scala (this was 2012ish). On the internal tools side, we created a gem and later a bower package (so vintage) that was a bootstrap-derived design system that worked across almost all 30 internal tools apps & services. I know other teams did the same (at least consumer and merchant), but I didn't work on those projects so I can't speak to them.

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.

[mountainriver]

> n 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.

This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev

[postmodern_mod3]

How so? Go does not prevent you from writing a monolith. Furthermore, Go does not actually require that you check the err return value of functions.

[likortera]

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]

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.

[likortera]

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.

[mountainriver]

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

[likortera]

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.

[weatherlite]

What do you mean there shouldn't be any more tests?

[mountainriver]

huh? Go has had ORMs for ages and they are fine

[wainstead]

> 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.

[mountainriver]

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?

[likortera]

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.

[likortera]

Just on time! https://news.ycombinator.com/item?id=31191700

[irvingprime]

Rails does not have to be written as a monolith. Typically, junior programmers who are trying to move very fast do that. Most of the places where I have talked to people who have a monolith are looking for ways to split it into services.

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.

[kenhwang]

Not sure Go is a very good example here, compiled languages have a huge maintainability advantage in monoliths (at the cost of compile time).

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.

[jaredcwhite]

"Rails monoliths are so much more difficult to maintain"

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.

[irvingprime]

Global? In "Rubyland?" No. That's just not true. Not at all.

[mountainriver]

That's totally fair, it seems to trend toward a monolith though, just from what I've seen

[inopinatus]

I work at a company with a large Rails monolith and it's a delight, and so is the monolith.

[aczerepinski]

I've had great experiences with both Ruby and Go. Both are a joy to write, and can handle most use cases. When I'm writing Ruby I sometimes wish I had Go's type system and lightning fast test suites. When I'm writing Go, I sometimes wish there were more conventions so I didn't burn so much time thinking through the absolute perfect way to architect every little thing. Still, they're both wonderful languages that hopefully fade to the background of your consciousness so you can focus on the actual business goals at hand.

[timuckun]

Use Sorbet. It provides a better type system than the go typing system.

[weatherlite]

> You want a scalable system that’s easy to write and will grow with you? Write basic Go service

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.

[mountainriver]

Go was designed to prevent this is why its great, Ruby was designed in a way that fosters bad dev practices

[hiyer]

A Go monolith would be just as hard to maintain as an RoR monolith. This is not a shortcoming of the framework.

[mountainriver]

Nope, Go is more opinionated and was designed to work on large teams and codebases with junior engineers. It enforces best practices where Ruby just lets you shoot yourself in the foot

[hiyer]

Ruby may not be opinionated but Rails is - convention over configuration is a core philosophy. It's one of the reasons it's so easy to get started with.

[waplot]

Monolith vs microservices is not the problem. It's architecture and code design in most cases.

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...

[postmodern_mod3]

You can write "complected" monoliths in any language. You can also write SOAs in any language. If you need native performance, Crystal is a better option, as it provides much of the same syntax, semantics, and stdlib as Ruby, but with Strong Typing. Go is a bit too simple.

[gls2ro]

Why is a disaster?

I ask this genuinely as I am interested to see what pain point people have with Rails.

[ysavir]

Two primary reasons:

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.

[phillmv]

in my experience, the main pain point people experience is:

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.