Ruby vs. Python (Why Python Won and Ruby Didn’t)

The TIOBE numbers

The gap is bigger than most people expect.

TIOBE founder and CEO Paul Jansen said as much directly in his April 2025 breakdown of the index. His read: Ruby held its own against Python and Perl for years, and even stabilized while Perl declined - but Python's rise changed the math:

"...there is not much room left for Ruby."
- Paul Jansen, TIOBE Founder & CEO, on LinkedIn

One honest caveat: TIOBE measures how often people search for a language's tutorials and docs, not how much code is actually running in production. So don't take any single month's rank too literally. But a trend that holds in the same direction for twenty straight years isn't a measurement error - that part you can trust.

Ruby bet everything on Rails

Ruby's rise and fall tracks almost perfectly with Rails as a category. Between roughly 2005 and 2012, Rails was the framework - Twitter, early Airbnb, and Basecamp all ran on it, and "learn Ruby" basically meant "learn Rails."

Python had web development too. Django launched around the same time as Rails, give or take a year. But web dev was never Python's only job - it already had a decade of scripting, sysadmin tooling, and academic computing under its belt before Rails even existed.

So when the web development lane got crowded - Node.js showed up promising one language for your entire stack, and the JavaScript ecosystem exploded around it - Python just kept doing its other jobs while quietly picking up new ones. Ruby didn't have a second act to fall back on.

Why developers still defend Ruby

If you want to understand why some developers will defend Ruby to the death, you don't need a chart - you need five minutes of Rails creator DHH explaining why Python's __init__ physically pains him. It's a genuinely good argument, and it's worth taking seriously.

def initialize(name)
  @name = name
  end

def __init__(self, name):
        self.name = name

Same job - Ruby just skips the punctuation ceremony.

user.downgrade unless user.admin?

if not user.is_admin:
        user.downgrade()

The ? on admin? tells the interpreter nothing. It's a note left for the next developer.

Ruby's creator, Yukihiro "Matz" Matsumoto, has said his top design goal was programmer happiness - not raw performance, not parser simplicity, but whether writing the code felt good. DHH's summary of the effect: reading well-written Ruby "reads like poetry." Python, by contrast, was built around the idea that there should ideally be one obvious way to do any given thing - clarity through constraint, rather than clarity through expressiveness.

Neither philosophy is wrong. They're just optimizing for different readers.

Why good syntax wasn't enough

Beautiful syntax is a real competitive advantage. It's just not the biggest one, and here's the actual inflection point: a library, not a framework.

Specifically, NumPy - originally released as "Numeric" and renamed in 2006 - made Python viable for serious numerical computing years before "machine learning" was something people put on a résumé. Everything that came after (SciPy, pandas, scikit-learn, PyTorch) built directly on that foundation. Ruby never had an equivalent, because Ruby wasn't trying to be a numeric-computing language. It was trying to be a joyful web-and-scripting language, and for a good while, it succeeded at exactly that.

There's a neat historical echo here, too: Python's rise partly filled a vacuum that Perl left behind after its own long, unfinished transition to Perl 6 fractured its community. Ruby's story rhymes with that, just with a different cause - not a broken version upgrade, but a niche that got crowded out from under it by better-funded competition.

Show me the benchmarks

Here's the honest answer to "which one is faster": it depends far more on your framework and workload than on the language's name on the tin.

• I/O-bound web apps (the bulk of typical backend work): Ruby and Python land roughly in the same neighborhood - your database queries and network calls dominate, not the interpreter.
• CPU-bound numeric work: Python usually pulls ahead, but that's thanks to native libraries like NumPy doing the heavy lifting in C, not the interpreter itself being faster.

Then there's the benchmark that ruins the tidy narrative. One public head-to-head pitted a simple Ruby web server (Roda) against Python's FastAPI on identical hardware:

Source: a single open GitHub benchmark, 4 cores, one specific endpoint. Not a universal ruling on either language - a good reminder that framework and config choices can swing results far more than the language does.

Both ecosystems have also been racing to close their historical performance gaps with JIT compilation: Ruby's YJIT (built by Shopify) targets 3x the speed of Ruby 2, while Python leans on projects like PyPy for similar gains.

Ruby isn't dead, it's just not trending

"Declining on a search-engine index" and "irrelevant" are two very different things. Here's what's still running on Ruby, quietly, at scale:

Worth noting: a mature ecosystem asking fewer questions on Stack Overflow can just mean fewer new problems left to solve, not fewer developers solving them. Ruby is less "dead language" and more "city that stopped issuing press releases." Still very much occupied.

Which one should you actually learn?

Honest, no-hedging version:

On that last beginner point: most learning resources and community size favor Python, but that's an ecosystem advantage, not a syntax one - Ruby is arguably just as readable for a first-timer.

Frequently asked questions