Is Ruby Dead? Only if you want to use it like it’s 2013.

Show of hands – who’s still using Ruby in 2021? *raises hand* Although, it’s debatable that any of us are using Ruby in 2021. We’re certainly not using the Ruby that people were using from 2010-2016, the Ruby golden era. It kinda feels like Ruby is a failing empire in it’s last days. Nothing really works right, and the only people still living here are tied down by obligations such as technical debt.

Take RVM. You know RVM, right? In 2013 it was the thing. If you weren’t using RVM (or it’s perplexingly nearly identical yet stubbornly also extant clone rbenv) you weren’t a real Ruby programmer. Probably. Or something. But it doesn’t matter, because you don’t use RVM anymore. You run ruby entirely within a docker container, because your Gemfile long ago grew to the length of several novels, and you can’t actually keep them all working across MacOS upgrades. “I hear MacOS 12 breaks the andand2 gem” you overhear. You wonder if you’re using that gem. You probably are, by virtue of it existing, and one of the many waves of Ruby programmers, with an average of 1.5 years tenure at any given company, probably dropped it in there for like, one unit test.

But getting back to RVM. The website is still there, and it’s still the best way to install multiple Ruby versions and manage dependencies. This is something I always laughed at PHP and Node and Python for not having. And NVM and PyEnv just felt… lacking. Well joke’s on me, now RVM is also lacking in similar ways. For instance, you search for “rvm install” on Google, which takes you directly to this page: RVM: Ruby Version Manager – Installing RVM …where you find a gpg command… which doesn’t actually work because “” has gone dark sometime in the last few years.

Then there’s system libraries. Ruby always over-relied on system libraries. Libxml, openssl, etc. There isn’t even an automatic fallback if you’re missing one. RVM just fails to install ruby. MacOS, following the decade-old Apple tradition of “MacOS? Never heard of it. Oh yeah, I think we still have a few employees working on that” breaks openssl pretty much every release, every year, on the dot. So RVM and/or the Ruby maintainers need to know about what poking and prodding they need to do to make Ruby work on the latest MacOS. Back when Ruby was flush with developers, who were all running Ruby on their machines, that was trivial. Someone would file a bug report (or hundreds of people would file bug reports), and dozens of people would submit patches, and one would be approved, and good game. Congrats, your rickety, bleeding-edge, syslib-dependent language lives for another year. Yay!

Of course, as I mentioned, no one runs Ruby locally anymore. Apps are simply too complex to run outside of docker. I personally believe that docker has increased development friction and enabled a whole new class of dependency bloat, but that’s beside the discussion at the moment. Another factor is the rise of Single-Page App frameworks. When React hit the scene, it was just a matter of time before people switched from whatever ugly unmaintainable ERB or HAML (ew) templates they were using, and switched to glorious JSX. That, and the general superiority of SPAs for development experience and user experience, led people to pretty much relegate Ruby to the deep backend, only serving CRUDdy APIs and maybe checking auth. Maybe.

And then there’s Rails. As SPA frameworks like Angular started to gain mindshare and momentum, Rails reacted pretty badly, by hastily stuffing in features like Turbolinks, and reengineering Sprockets several times to try to get in front of the ball. It was all in vain, of course. Turns out developers really just wanted to minify a separate Angular or React app and serve it at the webserver level, even in development. But Rails kept going, trying to value-add with things like Action Mailbox and Active Job and ActionCable. Of course they had to re-architect Rails and change key APIs and config settings, meaning that upgrading to Rails 4 or 5 or 6 is still a headache, or bordering on a quarter-long OKR, depending on who you are. But you have to upgrade, because old major versions get summarily EOL’d after awhile, you know? And does anyone use this stuff? Unlikely. Everyone knows monoliths are bad.

In comparison to PHP, another language which had it’s day and lost it, Ruby feels like a true ghost town. The villagers left all at once when the gold mine ran dry. PHP has been mining steadily for that same decade, managing to maintain a sense of order and a slowly-improving developer experience. Ruby feels like everyone dropped their pickaxes and left overnight. As someone who keeps tripping over digital pickaxes like RVM, I can’t help but feel nostalgic.

One response to “Is Ruby Dead? Only if you want to use it like it’s 2013.”

  1. […] I believe that programming languages/environments/frameworks/tools decay over time. Not through lack of contributions, but through bad contributions. It seems to be the common belief that software gets better over time. But people also believe that software gets “old” and “crufty” somehow. Magically! It especially happens to the code in your tech stack. But it never happens to languages or tools. How did your C++ code get so bad? Why, previous employees at the company made bad decisions. Surely C++ didn’t get worse. Surely the C++ ecosystem and community didn’t regress, right? Didn’t everyone once use Ruby? […]

Leave a Reply

%d bloggers like this: