When DHH took the stage at Rails World 2026 and talked openly about going "pencils down" on hand-typing code—and about just how much Rust he and 37...
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
No spam. Unsubscribe anytime.
It seems like every framework or language is declared "dead" at some point, except by the people actually building and maintaining production systems with it. There's a pretty substantial difference between being dead and simply no longer being the hottest thing in development.
I think Forem is a particularly interesting example because you're demonstrating that Rails doesn't necessarily need to solve every problem itself to remain a viable foundation. Bringing Rust into the ecosystem for specific performance-sensitive operations seems like a pragmatic architectural decision rather than an indictment of Ruby.
I'm curious about a couple of things from your experience. First, what would actually convince you that it was time to move Forem away from Rails? And if you reached that point today, what framework would be your leading candidate?
Second, what has been the most challenging part of integrating Rust into the existing ecosystem? The performance improvements are compelling, but I'm curious whether you've encountered tradeoffs around debugging, testing, deployment, or long-term maintainability that weren't immediately obvious.
And perhaps the broader question: Do you encounter any meaningful limitations from continuing to build on a framework that some developers perceive as less relevant, whether that's hiring, ecosystem support, or something else? Or is that perception largely disconnected from the realities of running Forem?
There's something refreshing about evaluating technology based on what it continues to deliver rather than where it happens to sit on the hype cycle.
I'll say that I don't like to overly rely on the heuristic of dismissing the decades of frameworks being "dead" — a bit of boy who cries wolf with that idea. Frameworks do die, but that's an aside.
I don't see us ever moving off Rails as a single step, I just don't see that being practical in and of itself— however there could be a Ship of Theseus scenario where we eventually replace so much we just wake up one day and we're "off rails" — but in the meantime I just think we're shrinking the scope of what the Ruby part of Rails needs to worry about.
My hope is that Rails adopts this pattern as a first class citizen for module rewrites— that is make it conventional for components to be rewritten in a lower level language. Rails has been pretty great at adopting different third-party open source software as highly baked in as standard or highly recommended defaults (Postgres, Tailwind) and I don't see why Rust would be that different.
Moving CPU-bound hot paths into
forem_nativeinside the Rails monolith avoids the fixed operational tax of splitting out a separate microservice. Extracting a service buys language flexibility at the cost of a network hop, duplicate auth, and a second deployment pipeline. When coding agents lower the labor cost of writing Rust wrappers and RSpec differential specs against1,000+randomized inputs, keeping everything inside one process changes the build-versus-split threshold.Standardizing
bin/rails queryworks on the same economics. Teams running autonomous performance loops end up writing bespoke read-only Postgres wrappers to let agents inspect query plans without handing over an unrestricted console. Promoting that read-only schema and explain contract to a framework command cuts duplicated audit work across every app.I managed to write this without referring to the common phrase "Rails is Dead"— which has been a common refrain since the beginning of Rails.
Ruby on Rails developers have often joked about this— but the AI revolution has made me personally much less confident in the future of Rails (not that it needs to be a leading technology— but we'd like to see it persist in viability beyond purely legacy).
I think the pattern of starting with traditional Ruby (much of which can be itself made radically performant under the hood) and substituting internal modules as the pieces settle, is a really viable pattern.
I watched DHH’s talk on YouTube too! Really interesting stuff. 😸
I’m not deeply experienced with Ruby or Rails, but I recently built an OSS tool called type-tune. It originally started in TypeScript, and partly inspired by DHH’s discussions around Rust, I rewrote it entirely in Rust mainly for performance.
Overall, I’m glad I did it, but I also have some regrets. Performance is great, but the project definitely became more complicated to operate and maintain than when everything lived in TypeScript.
That experience made me think less in terms of “Rust replaces the old stack” and more about where each technology should live.
So saying “Rails is dead” because some lower-level or CPU-heavy parts move to Rust feels too simplistic to me. In a large production codebase, keeping Rails for the higher-level application structure while moving the right hot paths to Rust seems like a very reasonable evolution.
Maybe the important question isn’t “Which language or framework wins?”, but “Which responsibilities should each layer own?”
Thanks for writing something much more nuanced than another “Rails is dead” take. Really enjoyed this one! 🙌
Ironically I did not watch the talk until the other day. I had heard about the general dialog around it, but I'd basically reached a lot of the same conclusions independently.
I'm so old that I remember when people were saying Ruby on Rails would be the end of software development because you could suddenly build an entire website in 20 minutes! 😂
The detail that stuck with me is the 54x faster markdown preprocessing with 97 percent fewer Ruby objects allocated. That is the kind of result that makes the hybrid approach easy to defend: Rails keeps the conventions and the legibility, and Rust takes the hot paths that actually hurt. The bin/rails query idea feels like the same instinct applied to tooling. If read only query inspection becomes a standard verb, a lot of bespoke team scripts disappear into one shared convention. Great piece, and the production numbers make the argument much stronger than any framework loyalty claim could.
I think this is actually a pretty good argument for keeping Rails around. Not everything needs to be rewritten in Rust, just the parts where it makes a measurable difference. The 75% latency improvement is pretty impressive too :D
The obsession with wrapping remote APIs into multi-layered agent abstractions is creating massive hidden latency and failure cascades in production.
If you profile real-world workloads, bare-metal local inference (via direct C++ / llama.cpp or vLLM bindings) consistently beats fragile cloud wrappers on both predictability and cost. Tooling should eliminate abstraction penalties, not compound them.
This is my first time working with either Ruby on Rails or Rust, so all of the material here is new to me. However, the architecture model got my attention - keeping the Rails framework as a base and using Rust for critical parts, instead of rebuilding the whole thing from scratch.
Really cool to see how various tools can complement each other instead of competing. Learned something new!
Fantastic read! ❤️
"Rust inside the monolith is a superpower" - yeah that says it all ...
Ruby isn't going anywhere, but the architecture of Rails (coupled with AI) allows you to replace 'critical' bits and bobs with Rust - totally different from the (unrealistic) idea of rewriting your whole codebase in Rust!
Ruby/Rails is one language/framework that I haven't tried, I have heard great things about it, but I just haven't found a use case for me yet, hopefully one day.
I like the cover image @ben sir 🥰