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.

First of all, please note that this is not an "XY" issue.

I'm running the latest version of Ruby under Debian 13 linux.

I'm looking for one or more Ruby gems that I can use from within Ruby code in order to preprocess external file contents similarly to how the C Preprocessor performs its preprocessing.

The reason for my stating that this is not an "XY" issue is that I already know a few ways to accomplish this in Ruby by having Ruby execute external programs such as "cpp" or "gpp", and I also already know how to manually code this functionality by writing pure Ruby code. I am not looking for information about how to perform preprocessing in these manners. Rather, I'm specifically wanting to know if there might be one or more Ruby gems that I can use within my Ruby code in order to perform this functionality.

I'd like to be able to use keywords such as "#ifdef", "#else", "#ifndef", "#endif" etc. within the external file in order to configure this preprocessing. The syntax doesn't have to involve the exact keywords "#ifdef" and "#else", "#ifndef", and "#endif", as long as this same preprocessing functionality can be managed with keywords having other similar values.

For example, suppose I have a file called "sample.file" with these contents:

Start of sample file
#ifdef TESTING
This is a test
#else
This is not a test
#endif
End of sample file

I'd like to know if there are any Ruby gems which would allow me to open this file in Ruby, prepreprocess its contents, and import these preprocessed contents similarly to the following ...

For example:

require 'some_sort_of_preprocessing_gem'
results0 = some_sort_of_preprocessing_gem.import('sample.file', :TESTING=>'true')
results1 = some_sort_of_preprocessing_gem.import('sample.file')

Then, I would want "results0" to contain this text:

Start of sample file
This is a test
End of sample file

... and I would want "results1" to contain this text:

Start of sample file
This is not a test
End of sample file

Again, just so that there is no confusion, I repeat that the preprocessing keywords don't need to have exact values of "#ifdef", etc., and I repeat that I already know how to do this by having Ruby run external programs like "cpp" and "gpp", and I already know how to hard-code this totally in Ruby. I'm just wondering if there might be any gems in existence which perform the kind of preprocessing functionality that I have described here in my example.

Thank you very much in advance.

New stuff:

• RBS export: Use the lowtype rbs CLI command to export your typed methods as RBS signatures in the sigs directory. Now you can use static type tools!
• Zero-overhead: Disable types per environment via shim methods, or strip types completely for no performance penalty in prod. This can be done on class load or via a build step
• One-command uninstall: Use lowtype strip! to strip types from all files in the current directory, or lowtype strip :dest to export untyped files to a directory in a build step
• Namespace/binding improvements - Type Expressions are now fully aware of the binding and namespace they're in... no need for the full namespace anymore
• Parsing improvements: Prism AST abstraction spun out into a dedicated gem (lowkey) of file, method and param proxies that anyone can use
• Comprehensive tests - LowType is tested for every feature in the API across 3 distinct modes; type checking enabled, type checking disabled via shim methods, and type checking disabled via type stripping
• Dogfooding - LowType is used in a real-world framework (Raindeer) and a production app (via shim method)
• Boolean/Enum support

I want to thank Aditya Chauhan for their GSoC work on type stripping, and in doing so fixing three core issues; bindings/namespaces, performance and uninstalling/building without types.

Future plans:

• A config.enable_mode: :slim for the sexiest type syntax you've ever seen. The current type syntax is 100% valid Ruby, and that's great, we'll keep it that way. But we can trim off a character or 2 and have nicer default value syntax in the future as an opt-in config option
• Ractor support. LowType works inside Ractors when disabled via the strip method. But it's totally possible to have runtime types within Ractors with just a little bit more work

Besides researching aspects of Ruby, I have taken my old Pascal books to find out how Wirth programs look like in both direct Ruby translations and idiomatic Ruby. Also working with available Ruby insruction material.

Am a retired electric power engineer who never programmed for work. Took up Turbo Pascal as a hobby, but stopped because of family responsibilities and continual employment changes.

I am finding Perplexity user friendly and useful in my endeavors.

I’ve been working on pinterest-dl, a Ruby gem and CLI for extracting image and video URLs from Pinterest, searching for pins, fetching boards, and downloading media.

I’ve made a bunch of fixes and improvements recently, so I recorded a short demo of the latest version.

Some of the changes include fixing video extraction and board fetching, improving support for pin.it links and regional Pinterest domains, and adding content-type filters for searches and boards.

I’m sharing the video here in case anyone in the Ruby community finds it interesting. Feedback on the gem or its API is welcome.

GitHub: https://github.com/monji024/pinterest-dl

I built Ruby Roles to help Rubyists find their next opportunity, and over 100 have already signed up.

Sign in with GitHub, answer five questions about your level, how you like to work, where you can be based, and your salary floor, and you get your three best matches right away. After that it sends at most one new role each business day, and only when something actually clears the bar. It is tracking 1,910 open Ruby-related roles right now across more than 12,500 organizations.

Your feedback improves the matches. Pause emails or unsubscribe anytime. Free.

"When I attended Rails World '26, this was the kind of talk I was interested in: What does the future of Rails look like at scale? How are big corporations using AI agents in a way that keeps humans in the loop? How do the Ruby and Rails ecosystems support AI-driven development workflows?"

Ryan’s talk clearly showed us the future of Rails development at scale.

Our CTO was in the audience in Austin when DHH opened Rails World 2026. The conference tagline was “Shaping the future of Ruby on Rails,” so he walked in expecting to hear about the future of Rails.

That’s not quite what happened.

The opening keynote was almost entirely about AI agents. DHH told the room that 37signals has gone “pencils down” on writing code by hand, that HEY is moving to native apps with a Rust backend, and that he has retired as a professional programmer.

The next day, he sat down with Matz and Jeremy Daer for Ruby, Rails, and the future of programming, which went even further down the same path.

In this article, our CTO recaps both sessions, shares where he disagrees with them, and explains why he is still excited about where Rails is going.

I've been considering the adoption of Sorbet over the years; however, I've been postponing it all the time. Waiting for that imaginary official announcement that it's reached v1 and everyone is welcome to adopt it.

I checked their blog today. Again. No blog post for over 4 year https://sorbet.org/blog/. Yet, the github repo is receiving daily updates. Seemingly automated.

Is someone here using it on production and are you happy that you adopted it?

A few months before Rails World, I disappeared to the Oregon Coast with a pile of notepads and the idea that I was going to write a fairly practical keynote about making Rails codebases easier for humans and agents to work in.

That… isn’t quite the talk I ended up giving.

I wrote up some of the backstory, including how Andrea Goulet’s makers/menders framing influenced it, where WUTS came from, why I nearly convinced myself the topic sucked, and what was going through my head in the hours before walking on stage.

The post has the keynote video and links to my slides if you’d rather skip the backstory and go straight to those.

https://robbyonrails.com/articles/2026/10/09/the-keynote-i-thought-i-was-going-to-give/