Why we still build with Ruby in 2025

1. Your subjective experience learning a new language is going to be up to you and how many languages you know. Ruby feels great from Java and C# to me, but maybe it won't for you.

2. The Rails guides (official) are great to learn the framework.

3. It's only relevant to learn the older versions of the framework if you're going to a company on the older versions. Realistically, 5, 6, 7, and 8 are all very similar and I would argue it's more important to start with the newest stuff and focus on upgrading apps the newest version than trying to learn the older versions (not for any particular reason, other than there have been meaningful improvements in later versions).

4. The source code, contrary to popular belief, is quite well-documented, and the official guides are also very well written. A lot of the "magic" is just DSL/plumbing that exists in the actual framework. I personally keep a copy of rails/rails locally so I can look at things when I want to, because it's really that readable.

Since it doesn't have as much interest from FAANG people treat it like its dead meat. Rails powers a ton of smaller apps (and some very large ones) but everyone thinks their idea is the going to be the second coming and therefore it needs all the insane optimizations that power Google etc.

I've been toying with Perl+CGI-scripts lately and find its super productive with the benefit that I can do serverless without the lock-in.

I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to reinvent the wheel as well.

I think its fine to use older technology if its the right fit for the problem, and since the tech is battle-tested, you can read up as to why it went out-of-fashion, and as a result can minimize the risks with using it. It's "predictably disappointing".

It's because it's not receiving a constant hype that other fullstack frameworks have, so people thing it's outdated. But in reality, Rails is boring, it's a beast and it just works

I think it's just so strongly associated with a certain era (10-15 years ago) that it's hard for people to get it into the present day. Also, Rails is so dominant in Ruby that there aren't libraries/frameworks for the "latest trends" with as much mindshare.

I wouldn't be against starting a new project in Ruby or RoR.

I feel its the MVC part that IMHO kind of sucks. I really dont like how it couples you to all sorts of frameworky stuff. A simple router is what you really need in 99% of cases.

It’s the same thing with php. I would say it’s probably because they are languages from the 90s, but then you have python and JavaScript which are from the same era too and people never question their relevance or “modernity”. All of these languages (even java) have been in constant development since then and all of them have modern features. Why are some considered modern and some outdated when they are all basically from the same era?

A truly modern language is Rust.

Agreed!

Rails has bad spa suppott.

Re: GitHub.

IF they do a rewrite, that should buy us at least 5 years, based on my experience with large-scale rewrites lol

Having been on Microsoft acquisition before, generally they encourage .Net usage for greenfield if possible but it’s pretty gentle encouragement. I’ve heard they are getting pretty pushy against C++.

Re: ZJIT: all development is happening in the open in the zjit folder of the ruby/ruby repo. You can follow along!

I think it's the Toyota Camry of languages. No, it's not the cool thing and won't turn heads or get you compliments.

But it'll take you very, very far for a very, very long time.

So much of what goes into a language choice involves things that aren't the language itself but the ecosystem around it. Documentation, standard library, third-party libraries, build and deploying tooling, and so on.

So a huge part of getting people to move from an existing tool they know with a well established ecosystem to a new tool that perhaps doesn't have that yet is getting those things in place (and then getting people to want to use them). I can imagine that being able to boostrap part of that process could help with the adoption of new tools.

The counter argument is that the friction behind these things is actually a benefit, as languages are only useful when they're shared and it doesn't make sense to have a huge range of languages that all mostly function the same but are just different synatcically. So it's a feature that it takes time for newer languages to gain traction, because it's essentially being tested for suitability and usefulness by a slowly growing number of people, at first the innovators, early adopters and early majority on the curve and later on the ones that perhaps can't afford to spend time on something that might not gen enough traction to last.

On a related note, I'm curious to know what the impact of generative AI on language-interoperability will be. Every time I see a suggestion that WASM and Interface Types is the thing that will finally allow me to use that weird but useful Python library in my Rust project, I always feel like unless there's a performance consideration involved I'd really rather just have everything in the same language, so the idea of automated translation of libraries at the source level seems like it could be useful. No need for language interop when you can quickly put everything into the same language.

Many times with JIT you don't even need to drop to a more performant language. You can actually get some speed gains by moving C library code back to Ruby so you don't have to pay the translation costs

> So just build in Ruby and when you hit a bottleneck, rewrite that bottleneck in C or Rust

Nowadays, yjit is so good that there is no real reason to use c extensions

> So just build in Ruby and when you hit a bottleneck, rewrite that bottleneck in C or Rust...

This is basically what we do at my startup. Though, some things we build elsewher from the start, knowing they need language specific tooling (like Python is best for working with LLMs).

You just can't beat the speed at which you can build business logic in Rails. Most features never hit the point of needing actual, raw performance so on 95% of what you build, you get to work incredibly fast. That still makes up for the 5% of features that you rip out and move elsewhere.