RubyConf 2026: Spinel, Roundhouse, and Why Ruby Was Never the Culprit

RubyConf 2026 ran 14–16 July in Las Vegas. It was the first RubyConf since the worst governance fight in the language’s history, and the first since two people independently decided that the way to make Ruby fast was to stop running it.

Those two threads sound unrelated. They are not. Both are about the same question — who is accountable for the parts of Ruby that everyone depends on and nobody owns — and both got answered, partially, in the same twelve months.

The year the community had to grow up

The short history, because it matters for everything that follows.

In mid-September 2025, Ruby Central revoked the access of the long-standing RubyGems and Bundler maintainers. The stated reason was supply-chain security and the need for formal operator agreements. The trigger, according to Richard Schneeman’s later report, was that André Arko — a RubyGems maintainer, a Ruby Central advisor, and on Ruby Central’s payroll for on-call engineering — had launched a Ruby version manager called rv and set up an organisation called Spinel Cooperative without telling anyone first.

What followed was ugly. Maintainers who had spent a decade on Bundler found themselves locked out of it. Several forked RubyGems into Gem Cooperative. On 17 October 2025, Matz ended it: repository ownership would transition to the Ruby core team, with Ruby Central continuing to run the infrastructure jointly. Not a victory for either side. A boundary, drawn by the one person everyone still trusted to draw it.

RubyConf 2026’s programme reflects a community still processing that. There was a panel called Once a Maintainer, with Allison Pike, Richard Schneeman, Jeremy Evans and Colby Swandale. There was a Jessica Kerr keynote titled Who are we Now?. There was a session on gem security run jointly by Ruby Central’s Marty Haught and the people who audit the supply chain from the outside.

Accountability in open source is not dead. It just turned out to be much harder to write down than anyone assumed, and considerably more expensive than a sponsorship tier.

Two compilers, one season

On 16 March 2026, Matz published Spinel: a self-hosting ahead-of-time compiler that reads Ruby source, performs whole-program type inference with no external annotations, and emits standalone C, then native binaries. Across 28 benchmarks it reports an 11.6× geometric-mean speedup over miniruby, and 86.7× on Conway’s Game of Life.

On 17 April, Sam Ruby published Roundhouse, which he had built in 275 commits over eight days. Roundhouse takes a different swing entirely: it treats Rails, not Ruby, as the specification. It ingests a Rails application into a typed intermediate representation and emits equivalent projects in C#, Crystal, Elixir, Go, Kotlin, Python, Rust, Swift and TypeScript — plus a Ruby round-trip that runs under CRuby, JRuby, or Spinel.

Neither knew about the other when they started. Sam Ruby’s own write-up of the coincidence is the best account of why both became possible at the same moment: Prism gave the ecosystem a robust embeddable parser, the Sorbet rollouts at Stripe and Shopify proved empirically that most Rails code types with almost no annotation, and agentic tooling dropped the cost of compiler-shaped work from years to weeks.

Where they draw the line

Both projects hit the same cliff from opposite directions: no eval, no send or method_missing or define_method driven by runtime data. Everything else is a trade.

	Spinel	Roundhouse
Specification	Ruby the language	Rails the framework
Output	C, then a native binary	Nine languages, plus a Ruby round-trip
Optimises for	Ruby fidelity, memory footprint	Program coverage, target reach
Self-hosting	Yes	No — the runtime is Rust

They now feed each other. Roundhouse’s emitted Ruby is deliberately the small-classes, no-metaprogramming shape Spinel was built to compile, so an arbitrary Rails app can be lowered by Roundhouse and then compiled by Spinel into a standalone binary. When Sam Ruby filed a six-line repro against Spinel for a default-argument bug, Matz closed it the same morning.

The number that should bother you

Here is the measurement that reframes the last decade of Ruby performance discourse. It comes from Roundhouse’s benchmark suite, holding the language, the JIT, the web server and the hardware constant, and changing only the shape of the code being run.

Configuration	req/sec	p50	RSS
Rails on CRuby + YJIT	481	128.9 ms	328 MB
Rails on JRuby	1,057	55.7 ms	1,169 MB
Roundhouse emit on CRuby + YJIT	5,283	12.0 ms	135 MB
Roundhouse emit on JRuby	26,108	2.3 ms	982 MB

Rows one and three are the same Ruby, the same YJIT, the same Puma, on the same machine. The only difference is the shape of the program.

Then look at what the JIT contributes in each case. Toggling YJIT on stock Rails moves throughput about 5% — inside the noise. Toggling the same YJIT on the lowered code moves it about 46%. Swapping runtimes tells the same story: stock Rails gains 2.2× moving to JRuby, while the emitted code gains 4.9×. Thirty years of JVM JIT engineering is aimed at monomorphic call sites and shapes that hold still. Rails’ runtime metaprogramming manufactures precisely the opposite.

So what was the culprit?

Not Ruby. Not really YJIT either, which turns out to have been waiting patiently for input it could specialise.

The cost is that a Rails application re-derives, on every single request, a large set of facts that cannot possibly differ between requests. Which columns a model has. Which callbacks fire. How a route maps to an action. Which partial renders which local. All of it resolved dynamically, per request, forever.

That dynamism is not an accident or a bug. It is exactly what made Rails productive enough to build a career on. has_many :comments is wonderful to write partly because it resolves at runtime. The compiler argument is not that the convention was wrong; it is that the convention already contains enough type information to be resolved once, at build time, and then never again. Roundhouse’s inference recovers whole-app types for Mastodon in roughly two seconds, in a browser tab, with no annotations and no database.

What none of this changes on Monday

Now the cold water, and both authors are commendably blunt about it.

• These are CPU-bound microbenchmarks on small fixture apps, single-worker, with SQLite in-process. Your production app is I/O-bound and talks to Postgres over a network.
• The metaprogramming exclusion list is real. If your codebase leans on method_missing or dynamic send, you are outside the supported subset today.
• Roundhouse’s own documentation says, in as many words, not ready for production. Spinel is younger still, and Ruby 4.0’s ZJIT is itself explicitly not recommended for production until 4.1.
• Nobody has run a real business on any of this yet.

The right way to hold this research is as a signal about where the ceiling is, not as an upgrade path. It tells you that when your Rails app is slow, the answer is almost never “Ruby is slow” — and that the industry’s reflexive rewrite-it-in-Go response has been solving the wrong problem at enormous cost.

Where this goes next

Watch three things over the next year. Whether ZJIT actually overtakes YJIT in Ruby 4.1, which is the core team’s stated goal. Whether Roundhouse’s type inference gets unbundled from the transpiler and shipped as the LSP and MCP server it is already capable of being — that would be useful to every Rails developer immediately, whether or not they ever compile anything. And whether the governance settlement holds when the next disagreement arrives, because the fracture report was closure, not a fix.

How we think about this at Boolean Solutions

We build and rescue Rails applications for SaaS companies and startups, and we have sat in a lot of rooms where someone proposes a rewrite in a faster language because the dashboard takes four seconds. Almost every time, the dashboard takes four seconds because of a nested N+1 query and a missing composite index, and it can be fixed in two days rather than two quarters.

What the 2026 compiler work adds is a rigorous, benchmarked argument for something we have been saying from experience: measure first, and be extremely suspicious of any performance plan whose first step is changing languages. If you want a second opinion on a slow application before you commit to a rewrite, talk to us — we will tell you honestly whether the problem is your architecture, your queries, or genuinely your runtime.

Further reading

• Two Compilers, One Moment — Sam Ruby on why Spinel and Roundhouse appeared in the same season
• Numbers Without Conclusions — the benchmark methodology and its caveats, written by the person with the most to gain from overselling them
• Roundhouse — the project, its conformance oracle, and the Blog, Lobsters and Mastodon test apps
• Ruby 4.0.0 Released — ZJIT and Ruby::Box, shipped on Christmas Day 2025
• The Transition of RubyGems Repository Ownership — Matz’s statement closing the governance dispute
• Is Ruby Too Slow for Web Scale? — Nate Berkopec making the I/O-bound version of this argument years before the benchmarks existed