Living in the Weimar Era of Ruby

By Julik Tarkhanov | October 12, 2026

There has been significant discourse surrounding the keynote delivered by DHH at RailsWorld. To my ears, it sounded like the manifesto of someone experiencing a profound, albeit exhausted, existential crisis.

When the headline speaker at a conference—let's call it CareConf—which he himself championed, essentially tells the audience, "I don't care anymore, and you shouldn't either," it sends a jarring message.

The Decree from the Top

The "supreme leader's" thesis was straightforward: they performed a "vibe-rewrite" of HEY to boost performance, it worked, and consequently, they no longer need or value Rails.

I truly believe that instead of seeking applause through aggressive "truth-bombing," he could have simply stepped away from the toy he no longer enjoys—and left its community in peace.

However, the fact that the wealthy and famous lose interest in quality tools does not mean the rest of us must follow suit.

---

The Emotional Shift: From Despair to Discovery

I will admit, I spent a few days in a state of depression. This wasn't because of the "AI is writing all the code" narrative—I accept that the craft is changing. I am more concerned with the landscape of usage (a topic for another time).

It is an objective reality that LLMs are permanent. The era of manually typing every single character is over; the scales have shifted.

What actually depressed me was:

1. The apparent lack of affection for the Ruby ecosystem.
2. The disdain with which David dismissed the entire culture of Ruby and Rails just to achieve the goal of "running it on a single Raspberry Pi."

But upon reflection, I see something else: a renaissance. Even as prominent figures migrate to other stacks, those stacks are now more accessible because we no longer have to manually write the "gunk."

Defining "The Gunk"

Writing a detailed unpack of 7 little-endian integers isn't art; it's just tedious boilerplate. I won't miss it.

// Example of "Gunk" (Low-level struct packing)
struct Data {
    uint32_t id;
    uint32_t value;
};
// This is the tedious part we can now delegate to AI

Unless extreme speed is required—in which case we can apply "art direction" to the optimization—the gunk is irrelevant.

---

The Weimar Analogy

To understand where we are, we can look at the "interbellum" period of German history: the Weimar Republic.

It was a chaotic era defined by:

• Extreme inflation and unemployment.
• Squalid living conditions.
• The rise of fringe cults and wild cabaret scenes.

Yet, amidst this turbulence, the "Roaring Twenties" produced a staggering amount of whimsical and enduring art.

It was also a time of massive technological leaps: the proliferation of electricity, the birth of modern pharmaceuticals, and the rise of the automobile.

The core of the analogy is this: When the old order loses interest, when there is no one "in charge," and the ground is shifting, that is exactly when the most provocative work is created.

$\text{Turmoil} + \text{Industrial Change} - \text{Adult Supervision} = \text{Innovation}$

---

The Artistic Soul of Ruby

Ruby has always been an artistic endeavor, dating back to the early days of _why. The primary draw of Rails was its aesthetics. It avoided the "Dutchman" style of naming (where everything is smashed into one long word) and eliminated the confusion between attributes and methods. The language was, quite simply, aesthetically brilliant.

The Path Forward

With our new AI-powered tooling, we have become $1000\times$ makers. As José Valim suggested, it is short-sighted to simply move on. If we have the most powerful tools in history, why aren't we making our stack $10\times$ better?

While Rust is fast and its type system is robust, there is a world beyond it. We should be asking:

• Can we make Ruby (and thus Rails) truly elite at concurrency?
• Can we implement a type system for Ruby that provides guarantees even beyond those of Rust?
• Could we embed SQLite3 into Rails with a replication protocol to shrink the stack further than a single server?
• How do we preemptively eliminate bugs in critical areas like database pools?

We don't need to worry about ActiveSearch, but we can fundamentally evolve our stacks rather than just asking an agent to "crap out code."

For example, Phoenix remains the only framework with built-in "presence" because it is a deceptively difficult problem. Why aren't we solving these hard problems in our own backyard?

---

Gardens vs. Concrete

Why do we choose "Rust vibe-rewrites" over improving what we have?

The narrative suggests that our apps will magically become accelerated, opaque binary blobs of SIMD goodness, with LLMs translating our intent via: $\text{Comparison Testing} \approx \text{Reading Tea Leaves Matrix Coefficients}$

Why spend tokens tending to the gardens we already inhabit when we can raze them to the ground and replace them with glorious, sterile concrete?

Fortunately, the "razing" isn't the only thing happening. There were real problems with the Ruby runtime—things that were simply "too much" to handle manually. For instance, generating a PDF with a complex layout used to be a nightmare because there were no viable libraries...

---

PS: I say all of this with love ❤️