Ask HN: Is Ruby on Rails still relevant?

Do you have any evidence at all to support this or is it just a guess?

The fact that there's entries for Ruby and Ruby on Rails also makes me think this, perhaps this data was just parsed.

React Native devs are gonna probably get paid in Equity.

Contracted Rails devs are probably working on an enterprise product that is already mature and making money.

Or that the fast growing startups using it are large-scale now and hoovering up available talent. Github, shopify, airbnb, gitlab, coinbase, hulu, twitch, etc.

My personal experience (myself and my social group) suggests there's serious brain drain.

All my peers who started their careers with Rails that know it like the back of their hands have zero desire to ever work with it again professionally. They're all exceptional engineers who had no problems picking up/migrating to Scala/Rust without productivity loss.

On the other side, I see all the upcoming engineers that missed the initial Rails popularity wave. To them, Rails is often times much more frustrating than TS/Python offerings. There's very little freely available quality onboarding materials, getting the environment set up is incredibly frustrating with how fickle bundler has become, and deployments are still complicated.

My take is Rails is good for those who already know Rails, since the stability of it lets seasoned Rails developers carry forward all their experience. But for someone without that history, TS/Python frameworks offer a much faster/smoother onboarding process, especially with the massive familiarity advantage devs already have with Python/JS from schooling/web.

If you're going to go out of the way to learn a new language, why would you learn one that occupies the same space as one you already know?

I 100% agree with your first part, but offer a slightly different conclusion - Ruby on Rails heavily skews to small startups (for various reasons not worth getting into here). Startups also tend towards Senior engineers, because they don't have the bandwidth to train junior engineers. So those recruiters are often looking for "Senior Rails" engineers which is even harder to find.

If the above is correct, it presents an interesting question to junior engineers: is it worth it to learn Ruby on Rails as a junior engineer? While there are advantages to learning Rails (it's heavily opinionated, what you learn maps very well to what professional projects look like), there is more job supply in the "python + LeetCode" path (how that relates to competition - who knows).

Programming is not tied to geography unless you are dealing with physical equipment (you probably don't want three grocery store self checkout machines in your living room) or have any sort of security requirements for the project.

I'm good enough at English, and I've learned to collaborate somewhat effectively remotely, but if given the choice, I still prefer collaborating with people in person and speaking my native language.

They all started the projects from 2009-2013 picking Rails, the most popular web framework at the time: https://insights.stackoverflow.com/trends?tags=ruby-on-rails...

If you were to follow in their footsteps, you'd also be picking the top popularity web framework for your time, which as of now is things like Next.js and Django.

Big recent-era startups:

OpenSea (Django / Next.js)

Notion (Node.js)

ScaleAI (Python, Node.js, Next.js)

Substack (Node.js)

Rippling (Django / Next.js)

Shopify is another notable one.

Why is a disaster?

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

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

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.

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

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

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.

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

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.

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.

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.

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

I've never understood the Go / RoR comparisons. If someone goes from being a die-hard Rails fan to a die-hard Go fan, that feels very much like they're choosing their tools based on fashion / fandom vs. picking the right tool for the job.

Go and RoR couldn't be more dissimilar from each other. One is a relatively slow language with one of the most full-featured and robust frameworks available today, and one is a very fast language with relatively minimal tools for building web applications. The types of projects they're suitable for are completely different

I'm a die hard Ruby guy and now writing some Go and I pretty much hate it. I don't really care for performance or compile speed, I could barely care less. I want a good web framework with tons of community support and a language that lets me easily express my thoughts into code. I'm not getting that with Go.

Go is great until you need to interface with a C library via cgo then you are in a world of pain with segfaults and the general mismatch between goroutines and C's ideas about concurrency.

Hmm, SSR is used quite often, it has just reached the boring stage. Also, rust is too BDSM for rapid CRUD building needs.