Ruby Isn't Dead, It Got Boring — And Boring Is Why It Ships

TL;DR: "Ruby is dead" is a category error. It confuses hype velocity — how often a language trends — with shipping velocity — how fast a team gets a working product in front of users and keeps it running. Those are different metrics and they are not even correlated. Meanwhile Rails 8 (November 2024) quietly deleted the three things people actually left Ruby over: the Redis dependency, the Sidekiq-style job stack, and the Node build step. The reasons to leave got removed while nobody was tweeting about it. Boring is not the absence of progress. For a team trying to launch, boring is the progress. Here's the honest version — including the parts Ruby still loses on.

The obituary runs every year. The shipping never stops.

There is a genre of blog post that publishes itself annually. "Is Ruby dead?" "The decline of Rails." "Why we moved off Ruby." It has run, in some form, every year for over a decade. It is one of the most reliably recurring pieces of content in our industry, which is itself the tell: you do not need to keep re-announcing the death of something that is actually dead. Nobody writes "is COBOL dead" think-pieces, because nobody's emotionally invested in the answer. The obituary cycle is a sign of relevance, not decline — you only keep eulogizing the thing people are still using.

And people are still using it. The companies you interact with daily — the largest code-hosting platform on earth, one of the biggest commerce platforms in the world, the company that invented the framework and still ships consumer products on it — run Ruby in production at enormous scale, today, in 2026, having had every resource and every reason to rewrite if Ruby were actually the liability the obituaries claim. They didn't. That's not nostalgia. Rewrites are expensive and these are companies that count. They stayed because the thing still ships.

So there's a contradiction to resolve. If Ruby is dead, why does the death keep needing to be announced, and why do the people with the most money and the most users keep shipping on the corpse? The resolution is that "dead" is measuring the wrong thing.

Define "dead" properly before you use it

When someone says a language is dead, ask them what metric moved. They almost always mean one of these, and they almost never mean the one that matters.

Mindshare is not usefulness. Most "Ruby is dead" arguments are, underneath, "Ruby doesn't trend anymore." Fewer conference keynotes, fewer hot takes, fewer "I rewrote my side project in it" posts. All true. Also irrelevant to whether it ships software. Mindshare measures how interesting a technology is to talk about, and interesting-to-talk-about peaks early — when a thing is new, unsettled, and everyone's still arguing about how to use it. A mature tool stops generating novelty content precisely because the arguments got settled and it just works. Falling mindshare is what success looks like from the outside. It is indistinguishable, on a graph, from death — and people keep reading the graph wrong.

Hype velocity vs. shipping velocity. Here's the distinction the whole obituary genre misses. Hype velocity is how fast a technology accumulates attention, stars, and conference talks. Shipping velocity is how fast a team using it gets a correct product in front of real users and keeps it up at 3am. These are different axes. They are arguably inversely related past a point: the technologies with the highest hype velocity are usually the youngest, which means the least settled, which means you spend shipping time relearning the stack every six months instead of building the product. Ruby has near-zero hype velocity in 2026 and that says nothing — nothing — about its shipping velocity, which is the only number a team trying to launch should care about.

The metrics that actually matter. If you want to know whether a stack is alive in the only sense that pays rent, don't count tweets. Ask: Is it maintained and releasing? (Ruby 3.x and Rails 8 — yes, actively.) Can you hire for it? (Yes, and we'll get to the honest version of that.) Can a small team get to production fast and stay there? (This is the whole rest of the post.) Are serious companies betting revenue on it now, not in 2014? (Yes.) Every one of those is green. The only red metric is "does Hacker News find it exciting," and that has never once shipped a feature.

This is, deliberately, the same move as the Elixir argument: judge the runtime by what it does at 3am, not by how it demos. Elixir is the interesting answer to that question. Ruby is the boring one. Both ship. This post is about why boring is underrated.

What Rails 8 actually changed (tested, not asserted)

Here is the part that makes the 2026 obituary not just wrong but out of date: the concrete, technical reasons people gave for leaving Ruby have been removed from the box. Not mitigated — removed. This is from the official Rails 8.0 release, finalized November 7, 2024 (rubyonrails.org, release notes), and I'm quoting it rather than characterizing it because the specifics are the argument.

The Redis dependency is gone. For years, "a real Rails app needs Redis" was true and was a legitimate complaint: another service to run, monitor, secure, and pay for. Rails 8 ships what the announcement calls "a trifecta of new database-backed adapters named Solid Cable, Solid Cache, and Solid Queue" — and they're database-backed, capable of running on SQLite. The release notes are explicit, per adapter: Solid Queue "replaces the need for Redis, also a separate job-running framework, like Resque, Delayed Job, or Sidekiq." Solid Cache "replaces either Redis or Memcached for storing HTML fragment caches." Solid Cable "replaces Redis to act as the pubsub server to relay WebSocket messages." That is the entire historical "Rails needs a pile of infrastructure" objection, addressed at the framework default level. The job framework and the cache server and the pubsub server collapse into "the database you already have."

The Node build step is gone. The other durable complaint — "I came to Rails to escape JavaScript tooling and now there's a node_modules and a bundler in my Ruby app" — is also addressed. Per the announcement, "Propshaft is a dividend from the mission to focus on #NOBUILD as the default path" and is "now the default for all Rails 8 applications," replacing Sprockets. The default path to ship JavaScript no longer routes through a Node build pipeline. The thing people specifically left to get away from is no longer in the default stack.

Deployment stopped requiring a PaaS. Rails 8 "comes preconfigured with Kamal 2 for deploying your application anywhere," and the generated Dockerfile "has been upgraded to include a new proxy called Thruster, which sits in front of the Puma web server." The implicit "...and you'll need Heroku to make any of this manageable" is gone too: the default new app is a container you can deploy to a plain server.

Sit with the timeline. The technical case for "we left Ruby because of Redis / Sidekiq / the Node step / the PaaS tax" was answered at the framework's default level in late 2024 — and the 2026 obituaries are still citing the pre-2024 version of the stack. They're not wrong about why people left. They're wrong that the reasons still exist.

The boring advantage is a real advantage

"Boring" gets used as an insult. It is, for a team trying to launch, a feature you should be willing to pay for. Here is the mechanism, not the platitude.

One framework decision instead of forty. Start a project on a high-hype stack and the framework is the first of forty decisions: router, ORM, migration tool, job queue, cache layer, auth, asset pipeline, test framework, the wiring between all of them. Each is a fork in the road, a comparison matrix, a "well it depends," and a thing your next hire has to learn because you chose it specifically. Rails' actual product is that it has already made those forty decisions, they cohere, and they're the same forty in every Rails app on earth. That is what "omakase" means and it is worth real money: the decisions you don't make are the schedule you don't lose, and the onboarding you don't have to write. Boring here means every Rails app looks like every other Rails app, which is exactly the property you want when a new engineer has to be productive in week one instead of month two.

Fewer moving parts to debug at 3am. This is the one that connects straight back to the Elixir post's frame. An incident's difficulty scales with the number of independent components that could be the cause. The pre-Rails-8 stack — app, database, Redis, Sidekiq, a Node-built asset bundle, a PaaS abstraction — is six things that can independently fail and three network boundaries between them where a 3am page can hide. The Rails 8 default stack collapses several of those into the database you were already running and already monitoring. Fewer services is fewer failure domains is fewer things to check while you're half awake. Boring infrastructure is infrastructure with a small incident surface, and a small incident surface is the single most underrated property a young company can have.

Settled means the answers are findable. A boring stack's other dividend: every problem you will hit, someone hit in 2017 and wrote down. The Stack Overflow answer exists. The pattern is in a book. The framework convention tells you where the code goes so you're not relitigating project structure. High-hype stacks trade this away — the answer to your problem might be in a GitHub issue from four months ago that's already out of date because the API changed. Maturity means the search results are correct. That is shipping velocity, directly.

None of this is exciting. That's the entire point. Excitement is a cost you pay in shipping time, and a team trying to launch should be extremely suspicious of how exciting its stack is.

The honest limits

A flagship post that only sells the upside is a brochure, so here is where Ruby genuinely loses, with no hedging — the same discipline I held the Elixir post to.

Hiring optics are real, even when the hiring is fine. You can hire Ruby engineers; the talent pool is deep and experienced precisely because the language is mature. But "we're a Rails shop" reads as less exciting to some candidates than a trendier stack, and perception is a real recruiting input even when it's not a real engineering one. You'll occasionally lose a candidate to vibes. The mitigation — strong engineers mostly care that the stack ships and the team is good — is true, but pretending the optics cost is zero is dishonest. There's a sorting effect worth naming, though: the engineers most repelled by "boring" are often the ones most attracted to novelty for its own sake, and novelty-seeking is not a trait you want concentrated in the people choosing your production architecture. The filter sometimes selects for you. That's a consolation, not a cancellation — you still pay the optics cost; you just occasionally get paid back in judgment.

AI/ML is still Python's, full stop. If your product's core is model training, data science, or heavy numerical work, that work is happening in Python and Ruby is not going to change that. The realistic 2026 architecture is Ruby/Rails for the product — the part that is web application, which Rails is exceptional at — calling out to Python (or a hosted model API) for the ML. Trying to do the ML in Ruby is fighting the ecosystem for no prize. Know which part of your system you're talking about before you pick the language for it.

Raw concurrency is still not its game. This is the direct handoff to the other two posts. For workloads that are fundamentally about massive concurrent connections or failure-isolated parallel work, Ruby's model is not the strong choice — that's the Elixir/BEAM argument for failure isolation, and the Go argument for concurrent network daemons. The honest framing: Rails is the best tool I know for the web application — the CRUD, the forms, the business logic, the admin, the 80% of most products that is not a concurrency problem. When the dominant pain genuinely is concurrency or failure isolation, that specific service should be Elixir or Go, and that's fine — "use Rails for the product, use the right thing for the hard concurrent edge" is a stronger architecture than forcing one runtime to do both.

Notice none of these limits is "it's dead." They're "here is the specific shape of work it's not best at," which is true of every tool and is the only useful form of criticism.

Verdict: pick Rails in 2026 when…

The honest checklist, not the fan version. Reach for Rails in 2026 when most of these are true:

• [ ] The product is mostly a web application — CRUD, forms, workflows, an admin, business logic. This is the 80% case and it's exactly Rails' home turf.
• [ ] The team is small and the deadline is real. The forty decisions Rails already made are forty you don't lose schedule to. Boring is fastest here.
• [ ] You want a small operational surface. The Rails 8 Solid stack collapses Redis/Sidekiq/Node/PaaS into "the database you already run." Fewer failure domains, fewer 3am unknowns.
• [ ] Your concurrency needs are normal web concurrency, not "hundreds of thousands of stateful connections that must fail independently." If they're the latter, that service is Elixir or Go — by design, not defeat.
• [ ] Your ML is an API call or a separate Python service, not the thing Ruby itself has to do.
• [ ] You can recruit on "we ship fast and the team is good" rather than needing stack novelty to attract people.

If most of those boxes are checked, the 2026 "Ruby is dead" narrative is not describing your reality — it's describing a stack that stopped existing in November 2024 and a metric (hype) that never shipped anything.

"Dead" was always a confusion of hype velocity with shipping velocity. Ruby's hype velocity is near zero and its shipping velocity is excellent, Rails 8 just deleted the last good technical reasons to leave, and the companies with the most to lose are still on it because — quietly, unexcitingly, reliably — it ships. Boring isn't the eulogy. Boring is the whole product.