Save StorySave this storySave StorySave this story
My little theory is that the concept of “imprinting” in psychology can just as easily be applied to programming: Much as a baby goose decides that the first moving life-form it encounters is its parent, embryonic programmers form ineradicable attachments to the patterns and quiddities of their first formative language.
For many people, that language is Ruby. It’s often credited with making programming “click”; imprintees speak of it with a certain indebtedness and affection. I get that. I wrote my first “Hello world” in an awful thing called Java, but programming only began to feel intuitive when I learned JavaScript (I know, I know) and OCaml—both of which fundamentally shaped my tastes.
I arrived somewhat late to Ruby. It wasn’t until my fourth job that I found myself on a team that mainly used it. By then, I’d heard enough paeans to its elegance that I was full of anticipation, ready to be charmed, to experience the kind of professional satori its adherents described. My dislike for it was immediate.
To arrive at a language late is to see it without the forgiving haze of sentimentality that comes with imprinting—the fond willingness to overlook a flaw as a quirk. What I saw wasn’t a bejeweled tool but a poor little thing that hadn’t quite gotten the news that the world of programming had moved on.
Ruby was created in 1995 by the Japanese programmer Yukihiro Matsumoto, affectionately called “Matz.” Aside from creating the only major programming language to have originated outside the West, this Osaka-born practicing Mormon is also known for being exceptionally nice, so much so that the Ruby community adopted the motto MINASWAN, for “Matz Is Nice And So We Are Nice.”
Befitting this, as well as its pretty name, Ruby is easy on the eyes. Its syntax is simple, free of semicolons or brackets. More so even than Python—a language known for its readability—Ruby reads almost like plain English.
Programming languages are generally divided into two camps: statically typed and dynamically typed. A static-type system resembles a set of Legos in which pieces interlock only with others of the right shape and size, making certain mistakes physically impossible. With dynamic typing, you can jam pieces together however you want. While this is theoretically more flexible on a small scale, that freedom backfires when you’re building large structures—certain types of errors are caught only when the program is running. The moment you put weight on your Lego footbridge, in other words, it slumps into a useless heap.
Ruby, you might’ve guessed, is dynamically typed. Python and JavaScript are too, but over the years, those communities have developed sophisticated tools to make them behave more responsibly. None of Ruby’s current solutions are on par with those. It’s far too conducive to what programmers call “footguns,” features that make it all too easy to shoot yourself in the foot.
Critically, Ruby’s performance profile consistently ranks near the bottom (read: slowest) among major languages. You may remember Twitter’s infamous “fail whale,” the error screen with a whale lifted by birds that appeared whenever the service went down. You could say that Ruby was largely to blame. Twitter’s collapse during the 2010 World Cup served as a wake-up call, and the company resolved to migrate its backend to Scala, a more robust language.
The move paid off: By the 2014 World Cup, Twitter handled a record 32 million tweets during the final match without an outage. Its new Scala-based backend could process up to 100 times faster than Ruby. In the 2010s, a wave of companies replaced much of their Ruby infrastructure, and when legacy Ruby code remained, new services were written in higher-performance languages.
What’s more, everything Ruby does, another language now does better, leaving it without a distinct niche. For quick scripting and automation, Python, JavaScript, and Perl were strong competitors. Python, though also a slow language, carved out a dominant niche in scientific computing and became the de facto language of AI. JavaScript came to dominate the web. And Perl, well, is dying—which I’m not sorry to see. Ruby now finds itself in an awkward middle ground.
You may wonder why people are still using Ruby in 2025. It survives because of its parasitic relationship with Ruby on Rails, the web framework that enabled Ruby’s widespread adoption and continues to anchor its relevance.
When Danish developer David Heinemeier Hansson, aka DHH, released Rails in 2004, Ruby ceased to be the province of nice Japanese programmers. DHH is a kind of photographic negative of Matz, a handsome firebrand with equal parts charisma and dogma—so much for MINASWAN—who likes to win public Twitter feuds and race car championships in his spare time.
In that prelapsarian era between the rise of Web 2.0 and the Facebook IPO—when Silicon Valley was awash in the jubilation of TechCrunch Disrupt and blissfully unaware of the impending techlash—Rails was the framework of choice for a new generation of startups. The main code bases of Airbnb, GitHub, Twitter, Shopify, and Stripe were built on it.
In the early 2000s, when building web applications was cumbersome, Rails offered a one-stop shop for developers. Instead of manually wiring together a database, a frontend, and a backend, Rails provided a packaged solution that simply worked. It was one of total integration—like a compact Usonian house by Frank Lloyd Wright where every detail is designed to fit into a single, unified vision.
Yet this was also an era that underestimated just how enormous the web would become. Try to remodel the kitchen or add a second story to a Usonian house and the unity becomes a liability. The house, initially designed to host a few well-behaved dinner guests, was now expected to function more like a convention center accommodating millions of unruly visitors.
I’m not the only person who’s bearish on Ruby. On Stack Overflow’s annual developer survey, it’s been slipping in popularity for years, going from a top-10 technology in 2013 to 18th this year—behind even Assembly. Among newer developers, Python and JavaScript rank much higher. Ruby persists, for now, as a kind of professional comfort object, sustained by the inertia of legacy code bases and the loyalty of those who first imprinted upon it. But nostalgia and a pretty name won’t cut it.
