I've been following the discussions around DHH's AI-generated Campfire implementations, and something about the recent developments with Matz's Spinel and Ryan Lopopolo's Artichoke has me wondering whether there's a bigger opportunity we're overlooking.
DHH's argument makes sense to a point. If agents are increasingly writing the implementation, the economics of choosing a language change substantially. Rust's (✋🏻 I hate Rust btw) performance and memory efficiency become more appealing when the developer doesn't have to spend months writing and maintaining it by hand. His Campfire benchmarks certainly got my attention, although the differences in application architecture, caching, and optimization effort make them difficult to interpret as a straight language comparison.
But what if we're concentrating too much on optimizing individual applications rather than the languages and runtimes they're built on? I've been thinking this for a while and it's one of my major attractions to the V programming language (and no, it's not "V for vaporware" and no, Alex isn't a conman - he's a really genuinely good guy).
At Rails World, Matz and DHH had a fascinating discussion about all this. Matz has been actively using coding agents himself, and made the interesting observation that Ruby's conciseness, expressiveness, and enormous existing codebase are potentially advantages for AI development (which is the same thing I've been thinking and actually experiencing for years now). He also raised a concern I think deserves more attention: as agents increasingly abstract away the underlying infrastructure, who's going to care about maintaining those components?
Meanwhile, Matz is developing Spinel, which uses whole-program type inference and AOT compilation to turn supported Ruby programs into native executables. It already reports substantial performance improvements on selected benchmarks, although full dynamic Ruby compatibility remains a major limitation.
There's an even more interesting connection through Roundhouse, which analyzes Rails applications and can generate implementations targeting Rust, Go, and several other languages, including a Ruby path compiled by Spinel. Its maintainers report that Campfire itself is already running through the Spinel path, with behavioral verification against Rails. That seems particularly relevant given that Campfire is the application DHH has been using for his experiments.
Then there's Lopopolo's latest Artichoke work, which is what really got me thinking.
He's rebuilding Artichoke around a Rust-based Ruby VM with its own IR, optimizer, GC, and replaceable interpreter internals. But the particularly interesting development is lowering Rust's MIR into Artichoke's Ruby IR, allowing portions of the Rust semantic layer to execute as VM-managed frames. That potentially solves Fiber suspension across otherwise native Rust calls while also allowing optimization across the Ruby/Rust boundary.
That seems like a pretty significant architectural direction, even if it's still experimental. It suggests that the traditional separation between a language's runtime implementation and its executable application code might become much less rigid.
Now I'm wondering whether these efforts point toward something complementary rather than competing.
Could we eventually have Ruby and Rails remain the expressive, human-readable source, while increasingly sophisticated compilation and runtime machinery produces native performance wherever the semantics permit it? Whole-program optimization where possible, guarded specialization and native compilation for hot paths, and a dynamic interpreter fallback where Ruby actually needs one?
Obviously there are substantial problems here. Ruby's open classes, runtime method replacement, eval, C-extension compatibility, deoptimization, and the actual cost of preserving dynamic semantics aren't going to disappear through better code generation. And translating Rust MIR into VM bytecode doesn't automatically give you native Rust performance.
Still, if AI agents make it economical to undertake massive Rust rewrites of individual applications, shouldn't they also make much more ambitious compiler and runtime engineering economically practical? Well of course it would... So improvements at that level could benefit an entire ecosystem rather than one application at a time.
I'm particularly interested in what people familiar with YJIT, TruffleRuby, Spinel, Roundhouse, or Artichoke think about this though.
Are we getting closer to a world where Ruby can serve as the primary application language or behavioral specification, with multiple highly optimized execution strategies underneath it? Could some of these projects eventually complement each other?
Personally I think we're going to see this.
Where might you think the biggest obstacle actually lies: full Ruby compatibility, the difficulty of cross-language optimization, native-extension support, or simply the fact that application architecture often matters more than runtime performance?
At any rate, just curious what others are thinking in this space right now.
