Why Ruby in 2024?

Date: 2023-12-09
categories: ruby;

As 2023 sputters in to a close like an old jalopy, I've decided it's time to dive into something new for the year to come. By new, I don't mean new (it's not!), but I do mean sparkly (it is!). The new thing for me is Ruby and its ecosystem.

"Ruby?" you say. "In 2024?" you say.

Yes.

Ruby is just such a cool language. At least for me, it sparks joy. Writing Perl makes me feel like an arcane wizard; writing Ruby makes me feel like a subtle illusionist. Everything can be molded, enticed, transformed. It is the perfect language for the creative and the bold.

I work with Python, TypeScript, C# and PHP during the day. These are good languages, solid languages, and they get the job done. But we work in the realm of pure concepts, bound only by the syntax of our programming languages and the limits of the silicon on which it runs. Ruby captures this magic of the infinite imagination. Programming Ruby feels more like walking in a sacred grove than working in a cubicle.

"What about static types?" you say.

Static types are cool. I like them and they help me. It is good and necessary to define things as a programmer. There's been a real resurgance of interest in static types in the last few years, and that's a good thing, on the whole.

Ruby's magic works differently, and it is precisely the dynamism of the spell it casts that allow my imagination to follow new tracks through the wilderness. Embracing the mindset of duck typing is a paradigm shift. It's like you're on a beach and you've been told not to get your shoes wet. So you can steer clear of the waves by keeping to the sand, or you can take your shoes off and wade into the ocean. Both strategies adhere to the rule, but standing on the beach and wading in the ocean are very different experiences, aren't they? I think you might solve problems differently with a different mindset.

Where types are necessary (and they will be), Ruby now supports optional typing through rbs, Sorbet, and others. I think this is great. It gives the benefit of adding types to help with tooling (IDEs, static analysis) without messing up the cool, mind-opening dynamism of the language.

If Ruby had added the types in the code (like Python), those types act as little mental shackles that pull you gently away from duck typing. It's no longer a thing that responds to a message, it's a Set[str]. Now everytime I see that line of code, it's harder to see the intent that it is, in fact, dynamic.

That was a lot of words to say "embrace dynamism". And, as with any dynamic language, write tests.

"It's slow, though," you say.

Maybe, by some measures and compared to something else. The same program written in Rust and adhering to the same spec will execute lots faster. Sometimes this matters a lot. Most of the time it doesn't. But you know that thing I said above about sparks joy? It's hard to underestimate the creativity that gets unlocked via enjoyment.

(And don't get me wrong, I really enjoy languages that get close to the metal. I believe in lean software that can last for decades. I write assembly language in my free time just for fun, for crying out loud! But most of the time, raw performance isn't the main thing.)

When performance does matter, Ruby is getting faster every year: see MJIT, YJIT, TruffleRuby, Crystal, native extensions in Rust, and all of the cool stuff orbiting around runtime performance.

"Ruby's not popular anymore," you say.

That's probably a good thing for anyone involved with Ruby.

Ruby feels different, partly because it's not the hype-train of the moment. The people involved with Ruby seem to really love the language and want to be here. The heyday of Ruby's hype as the "next big thing" may be over, and that's a good thing. What's left is a proven, stable, lovable language cared for by creative craftspeople who adore it.