Ruby on Rails used to be the hot band everyone wanted to see live. Now it feels more like a cult classic, still good, still playing, but to a smaller, more devoted crowd. And lately, some folks are wondering: is Rails on the path to becoming the next COBOL?
Yes, that COBOL. The 65-year-old language quietly running billions of lines of code inside banks, governments, and systems nobody wants to touch but everybody needs. On paper, the comparison seems extreme. But look closer, and you’ll start to see the shape of a long tail forming behind Rails. One that looks suspiciously like legacy.
Let’s dig in.
The rise of two titans
COBOL and Ruby on Rails couldn’t be more different in syntax, style, or era. They definitely share one thing though: both were once the default choice for a generation of developers.
COBOL, born in 1959, became the backbone of enterprise and government systems by the ’70s. If you’ve ever withdrawn cash, paid taxes, or waited for a check to clear, COBOL probably had something to do with it. Its dominance was complete, and it stuck — not because developers loved it, but because rewriting working software is expensive, risky, and often unnecessary.
Fast forward to the 2000s. Enter Rails: elegant, opinionated, and built for speed. DHH dropped convention over configuration like a mic, and the web dev world listened.
From 2005 to 2014, Rails was the framework of choice for startups, SaaS tools, and hacker weekends. Twitter, GitHub, Shopify, and Basecamp all bet big on it. For a while, every bootcamp taught it, every founder loved it, and every developer blog had a hot take on ActiveRecord callbacks.
It was a golden era. Until it wasn’t.
How Rails stacks up these days
Spoiler alert: not like it used to.
Once the backbone of every hot startup stack, Rails has quietly slipped from the spotlight over the past decade. While direct stats about framework usage can be hard to pin down, Ruby’s trajectory helps illustrate the shift. GitHub’s Octoverse reports show Ruby falling from #5 (2014) to #10 (2022) in language rankings. The TIOBE Index recently pushed it to 24th, with its CEO bluntly suggesting Ruby is “likely to go out of fashion.” Ouch.
Community chatter reflects the mood. “Rails is just not what it once was,” wrote one long-time Redditor. “The amount of jobs are way down and the pay is too.” Another chimed in: “It’s not COBOL — nothing that critical was written in it. Rails will eventually die.”
But not everyone’s buying the obituary. Rails defenders argue it’s simply matured. It might no longer be trendy, but it’s still incredibly efficient. It does what it promises. It allows small teams to build and ship real products fast, without the overhead of piecing together half a dozen libraries. In an era where VC money is drying up and lean teams are the norm, that’s a value prop worth paying attention to.
We see this play out with companies we work with, many of which are organizations that run massive products on large Rails codebases. One client, with a market cap north of $2 billion, has definitely felt the pull to rebuild in something “modern.” But when it comes to cost and risk, the appeal fades fast. Some functionality is being moved to other stacks where it makes sense, but the core will likely stay on Rails for years. There’s simply no silver bullet waiting on the other side.
COBOL walked so Rails could… maintain
To understand where Rails might be headed, it’s worth studying COBOL’s fate.
COBOL hasn’t been hot in decades, yet as of 2017, 220 billion lines of it still powered key systems. Some estimates say 43% of banking platforms and 95% of ATM swipes involve COBOL code. Why? Because rewriting complex financial logic that’s business-critical (and often undocumented) is risky and expensive.
The kicker? Most COBOL developers are nearing retirement. In 2020, some U.S. states literally had to beg for COBOL engineers to fix outdated unemployment systems. And those engineers? They’re making bank.
COBOL is a classic case of technological inertia. As a consequence, it’s created a niche economy where a small number of specialists quietly hold the keys to critical systems. And they command serious salaries for doing so.
Rails is starting to look a lot like COBOL
Just to be clear: Rails isn’t COBOL. But the trajectory? It rhymes.
Many foundational platforms still run on Rails. Shopify’s massive monolith? Rails. GitHub? Rails. Basecamp? Rails, obviously. These companies aren’t rushing to rewrite their cores in Elixir or Go. Instead, they’re optimizing what works — and contributing back to the Rails ecosystem in the process.
Rails roles are also becoming more specialized. Junior opportunities are scarcer; most open positions are for mid-to-senior engineers with years of experience. But those who are experienced? They’re doing just fine. Stack Overflow’s 2023 survey ranked Ruby as the 4th highest-paying tech globally. Senior Rails engineers in the U.S. regularly clear six figures.
This is where the COBOL parallel kicks in: high compensation, low visibility, and a shrinking pipeline of new devs.
Less hype, more output
Let’s kill the idea that Rails is frozen in time. It’s not.
Both Rails 7 and 8 are pushing forward with features that sidestep frontend fatigue. Hotwire, Turbo, and Stimulus let you build snappy UIs without reaching for React or Vue. Want realtime updates without drowning in JavaScript? Rails has that baked in.
On the backend, Ruby is still evolving. Turning 30 next year, it’s the same age as JavaScript, and it remains in active development. The Ruby 3×3 initiative, launched back in 2015, committed to making Ruby 3 three times faster than Ruby 2. That milestone was reached in 2020, and the momentum hasn’t stopped. Recent versions continue to bring performance gains through JIT compilers like YJIT and RJIT, as well as improvements to memory efficiency and startup times.
Rails 8 builds on this foundation. It is the version of Rails that remembers why people fell in love with it in the first place: fast setup, clear conventions, and a full-stack story that doesn’t require Kubernetes on day one. It even introduces “Solid Queue” for background jobs — no Redis, no drama.
And beyond the tooling, there’s still joy in writing Rails. As DHH recently pointed out in his post Coding should be a vibe!:
Disgruntled programmers have finally realized that an escape from nasty syntax, boilerplate galore, and ecosystem hyper-churn is possible. That’s the appeal of AI: having it hide away all that unpleasantness. Only it’s like cleaning your room by stuffing the mess under the bed — it doesn’t make it go away!
If developers are racing to offload coding to AI, maybe the problem lies in the stack itself.
Rails and Ruby offer a different path. It’s one that doesn’t require hiding the mess. Instead, they strip away unnecessary layers and let you build fast, clean, and human-readable code from day one. In that world, simplicity and elegance aren’t limitations. They’re advantages.
That’s also why we don’t skip upgrades. All of our active projects are already on Rails 7, and a couple have already adopted Rails 8. We use Hotwire and Turbo where it makes sense. Not because it’s fashionable, but because it solves real problems. Staying current gives us access to the latest features, but more importantly, it keeps our clients’ products secure.
Rails in a niche future
So, is Rails becoming the boutique skillset for aging SaaS platforms?
Maybe. And that’s not a bad thing.
Rails still excels at building internal tools, MVPs, and stable CRUD-heavy platforms — especially for teams that value clarity over cleverness. Its “boring is good” philosophy is a feature, not a bug.
The community remains active, too. The main Rails repo has seen over 6,500 commits and 1,500 issues closed in the past year. RailsConf draws a mix of grizzled veterans and Hotwire-happy newbies. Tools like StimulusReflex and view components show there’s still innovation happening, just at a more grounded pace.
The language and framework remain deeply aligned around developer happiness and productivity. Drastic deviations are unlikely to succeed, because what’s here doesn’t just work, it works very well. Newer languages and frameworks have their place, but Rails wasn’t built for the same constraints or audiences.
Rails isn’t a zombie. It’s simply not chasing trends anymore. It’s found its lane, and for the right teams, it’s still a dream to work with.
Not dead. Just different.
Ruby on Rails isn’t dying. It’s aging into its next role. Think less rockstar, more session musician. Still sharp, still useful, still quietly keeping the show running.
It might not be the framework new grads rush to learn, and it might not top the charts anymore. But for many companies, Rails is still a pragmatic choice. It delivers. It scales (when engineered well). And in a tech world increasingly obsessed with complexity, Rails dares to stay simple.
Smart engineering teams are well-aware: smart, stable software never goes out of style. So maybe, in 10 years, we’ll talk about Rails the same way we talk about COBOL: a relic, yes — but a reliable one. And in the end, reliability is underrated.
At Infinum, we’re here for both sides of the Rails story. Both if you’re looking to extend the life of a legacy system, or weighing Rails against shinier options for a new build. Check out our Rails Maintenance & Support services if your app needs some love (or a performance tune-up), or reach out if you’re on the fence about which tech stack fits your product best.
