Ruby the good, bad and ugly

Twenty years of programmer happiness, and the sharp edges nobody warns you about

22-12-2022

Contents

The first time Ruby genuinely surprised me, I was reading someone else’s code and understood it on the first pass without running it. That sounds trivial until you’ve spent a week deciphering a clever one-liner in another language. Ruby reads like a slightly terse version of what you’d say out loud — <code>3.times { puts "hi" }</code>, <code>[1, 2, 3].select(&:even?)</code> — and that legibility is not an accident. Yukihiro “Matz” Matsumoto started designing the language in 1993 and released it publicly in 1995 with an explicit, almost stubborn goal: optimise for the happiness of the programmer, not the convenience of the compiler. Nearly every strength and every wart in Ruby traces back to that one decision. I’ve shipped Ruby in production, run it in side projects, and inherited more than one Rails codebase that had been “clever” for years before I arrived. This is the field report — what’s genuinely a joy, what quietly costs you, and what will eventually bite the hand that fed it. <h2 id="why-ruby-feels-the-way-it-does">Why Ruby feels the way it does</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> Ruby is object-oriented in a way most languages only claim to be. In Java, <code>2</code> is a primitive and <code>2.toString()</code> is a special case. In Ruby, <code>2</code> is an object, <code>2.to_s</code> is an ordinary method call, and even <code>nil</code> has methods. <code>nil.to_a</code> returns an empty array. Numbers, strings, classes, and <code>nil</code> itself are all objects with methods you can call and, alarmingly, redefine. Once that clicks, the language stops having exceptions to its own rules, and code you’ve never seen before starts behaving the way you’d guess. Blocks are the other load-bearing idea. A block is a chunk of code you hand to a method, and they’re everywhere: iteration, resource management, DSLs. This is what lets a file get opened, read, and closed safely in one expression: <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-ruby" data-lang="ruby">File.open("config.yml") do |f| data = YAML.safe_load(f.read) data.fetch("database") end # file is closed automatically when the block ends, even on exception </code></pre></td></tr></table> </div> </div>The <code>do...end</code> block receives the open file, runs, and Ruby guarantees the file is closed afterwards. There’s no <code>finally</code>, no manual cleanup, no forgotten handle. That pattern — a method that sets something up, yields to your block, then tears it down — is the backbone of idiomatic Ruby, and it’s why the code stays flat and readable instead of drowning in nesting. <h2 id="the-good">The good</h2> The good news is mostly about leverage. Ruby lets a small number of people move fast, and it does so honestly rather than by hiding complexity behind magic you can’t inspect. The standard library and gem ecosystem are deep and mature. Two decades of “someone has already solved this” means that for the vast majority of ordinary tasks — HTTP, parsing, background jobs, database access — there’s a well-worn gem with sane defaults. Bundler pins your dependency graph reproducibly, which matters more than people admit; keeping that graph fresh is exactly the chore I automate with <a href="/story/renovate-bot-automated-dependency-updates-that-dont-break-everything/">Renovate Bot</a> so a Ruby project doesn’t quietly rot between releases. The testing culture is a genuine differentiator. RSpec and Minitest aren’t afterthoughts bolted on later — they’re woven into how Rubyists work, and the community norm is to test first and refactor with confidence. Because the language is so malleable, mocking and stubbing are trivial, which makes fast unit tests easy to write and easy to overuse. And it’s expressive without being cryptic. <code>users.reject(&:banned?).map(&:email)</code> says exactly what it does. Method chaining reads left to right the way you think about the transformation, and the Enumerable module gives every collection the same rich vocabulary. When Ruby is at its best, the code is close to executable prose. Ruby has also kept getting faster where it counts. Ruby 3.3, released on Christmas Day 2023, shipped major YJIT improvements — the Just-In-Time compiler now handles call sites and object shapes it previously bailed on, delivering multiples-faster results on some benchmarks while using less memory than the previous release. The M:N thread scheduler introduced in the same version reduced the cost of creating and managing threads, and Ruby 3.4 landed the following Christmas with further YJIT and parser work. Turning YJIT on is a one-line change with a real payoff on long-running web processes: <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-console" data-lang="console">$ RUBY_YJIT_ENABLE=1 ruby -e "p RubyVM::YJIT.enabled?" true $ ruby --yjit app.rb # or set the env var in your process manager </code></pre></td></tr></table> </div> </div>This matters because the tired “Ruby is slow” line is a decade out of date for a lot of real workloads. It was never fully true even then — Ruby spent most web requests waiting on the database — but the modern interpreter has quietly closed a chunk of the gap that the meme was built on. <h2 id="the-bad">The bad</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> The bad is the tax you pay for all that expressiveness, and it’s real. Raw single-threaded throughput is still well behind compiled languages. For CPU-bound work — number crunching, tight loops, heavy parsing — Go or Rust will run rings around Ruby, and no amount of YJIT closes that gap entirely. Ruby’s answer is that most web workloads are I/O-bound, where the language spends its time waiting on the database or the network anyway, and there it’s perfectly competitive. But if you’re writing a compute kernel, Ruby is the wrong tool and you should feel no guilt reaching for something else. Concurrency is the historically awkward part. The reference implementation has a Global VM Lock, so threads don’t run Ruby code truly in parallel on multiple cores. The traditional workaround is to run multiple processes — Puma and Sidekiq both do this — which works but eats memory, because each process carries its own copy of the runtime. Ractors (added in Ruby 3.0) promise real parallelism with isolated state, but years on they remain rough enough that most production code still leans on the process model. If you’re choosing where to put concurrent workloads, this is a genuine constraint, not a footnote. Dynamic typing is a double-edged sword that leans “bad” as codebases grow. There’s no compiler to catch a typo’d method name or a <code>nil</code> where you expected a <code>User</code>; you find out at runtime, often in production, often as the dreaded <code>NoMethodError: undefined method 'name' for nil</code>. Sorbet and RBS bring optional static typing, and they help, but they’re bolted on rather than native, and adoption is uneven. On a large team, the freedom that felt liberating at ten thousand lines starts feeling like a missing safety net at a hundred thousand. <h2 id="the-ugly">The ugly</h2> The ugly is where Ruby’s greatest strength — its malleability — turns on you. Everything is open, including things that shouldn’t be. You can reopen any class, including the standard library’s, and change it. This is called monkey-patching, and it’s genuinely useful right up until two gems both patch <code>String</code> in incompatible ways and you’re debugging behaviour that exists in neither library’s source. The method that’s actually running isn’t the one written anywhere you’d think to look; it was redefined at load time by code three dependencies deep. Metaprogramming compounds this. <code>method_missing</code>, <code>define_method</code>, and <code>respond_to_missing?</code> let you conjure methods that don’t exist until they’re called. Rails uses this brilliantly — <code>find_by_email_and_status</code> is not a method anyone wrote — but the cost is that “jump to definition” in your editor lands nowhere, because there’s nothing to jump to. New engineers on a metaprogramming-heavy codebase spend their first weeks confused about where behaviour even comes from. And then the small, sharp corners. <code>&&</code> and <code>and</code> have different precedence, so <code>x = foo and bar</code> does not mean what a newcomer thinks. <code>nil</code> and <code>false</code> are falsey but <code>0</code> and <code>""</code> are truthy, which trips up anyone arriving from another language. <code>frozen?</code> versus <code>freeze</code>, mutable string literals, the gap between <code>==</code>, <code>eql?</code>, and <code>equal?</code> — none of these are hard once learned, but they’re a pile of gotchas that the “programmer happiness” pitch quietly omits. <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-ruby" data-lang="ruby"># The classic precedence trap user = find_user or raise "not found" # assigns find_user, THEN checks — usually what you want user = find_user || raise("not found") # assigns the whole expression — also fine result = save and notify # 'and' binds looser than '=': result = save, THEN notify # almost never what you meant </code></pre></td></tr></table> </div> </div>The safe habit is to use <code>&&</code> and <code>||</code> for boolean logic and reserve <code>and</code>/<code>or</code> for control flow, but the language won’t stop you mixing them, and the bug that results is invisible until it isn’t. There’s a cultural dimension to the ugly, too. Because there are usually several idiomatic ways to write the same thing, and because the community holds strong opinions about which is “correct” Ruby, code review can drift into style arguments that have nothing to do with correctness. Rubocop, the standard linter, exists partly to end those debates by encoding a style guide you can argue with once and then obey — but a badly configured Rubocop can be its own source of friction, nagging about single-versus-double quotes while the actual bug sails through. The tooling is good; the trick is aiming it at real problems rather than aesthetic ones. <h2 id="where-ruby-earns-its-keep">Where Ruby earns its keep</h2> None of the ugly cancels the good. Ruby remains an outstanding choice for web applications, internal tooling, scripting, and anywhere a small team needs to turn ideas into shipped features quickly. Rails, which David Heinemeier Hansson extracted from Basecamp and released in 2004, is still one of the most productive ways to build a database-backed web app, and its convention-over-configuration philosophy rippled out into frameworks in nearly every other language. If you value shipping speed and readable code over squeezing out microseconds, Ruby pays you back. Where it earns its keep least is raw-performance work and very large, long-lived codebases maintained by rotating teams — the exact places where dynamic typing and pervasive metaprogramming turn from assets into liabilities. Every language makes trade-offs; Ruby just makes its trade-offs unusually visible. If you want to see how a language draws that line differently, the same good/bad/ugly treatment for <a href="/story/rust-the-good-bad-and-ugly/">Rust</a> is a useful mirror — it trades Ruby’s fluid ergonomics for compile-time guarantees, and reading the two side by side tells you a lot about what you actually value in a language. <h2 id="is-it-worth-learning">Is it worth learning?</h2> Yes, and not only for the jobs. Ruby will make you a better programmer in other languages, because it forces you to internalise objects, closures, and expression-oriented thinking in their cleanest form. Start with plain command-line scripts before you touch Rails, so you learn blocks, modules, and Enumerable on their own terms rather than through Rails’ considerable magic. Then decide, project by project, whether the trade you’re making — expressiveness and speed of development against raw performance and static safety — is the trade you want. For me, on the right kind of project, it almost always has been. Ruby optimised for my happiness, exactly as advertised, and I’ve stayed happy long enough to have earned the right to complain about the sharp edges. That’s about the highest compliment I can pay a tool.

Written by Smarc

Founder and editor of vo.rs. A lifelong tinkerer who self-hosts far more than is sensible, hardens Linux boxes for fun, and prods the latest AI tools to see what they can really do. The how-to guides here are the notes Smarc wishes had existed the first time round.

Tagged#programming #ruby #languages #rails

Ruby the good, bad and ugly

Twenty years of programmer happiness, and the sharp edges nobody warns you about

Related Content

Go, the good, bad and ugly

TypeScript, the good, bad and ugly

Rust, the good, bad and ugly

Bash, the good, bad and ugly