The editorial argues that the real headline is not the compiler itself but that Matz is personally writing it rather than delegating to a working group or endorsing a third-party effort. This represents a break from his historically conservative approach of preferring interpreter improvements and gradual JIT adoption over radical compilation strategies.
The editorial frames Spinel as a fundamentally different approach from YJIT and TruffleRuby, which optimize at runtime. Instead of making Ruby faster during execution, AOT compilation produces standalone native binaries before execution — the same strategy that made Go attractive — potentially delivering the order-of-magnitude leap that incremental JIT improvements like YJIT's 15-25% speedups could not.
The Hacker News submission of Spinel's GitHub repository pulled 279 points and 78 comments, indicating significant community interest. The high engagement suggests Ruby developers see AOT compilation as a potentially transformative direction for the language's future.
Yukihiro Matsumoto — universally known as Matz, the creator of Ruby — has quietly published Spinel, an ahead-of-time (AOT) native compiler for Ruby, on his personal GitHub account. The repository at `github.com/matz/spinel` landed on Hacker News and pulled 279 points, a signal that the Ruby community is paying close attention.
The fact that Ruby's creator is personally building an AOT compiler — not delegating it to a working group, not endorsing a third-party effort, but writing it himself — is the real headline here. Matz has historically been conservative about Ruby's execution model, preferring interpreter improvements and gradual JIT adoption over radical compilation strategies. Spinel represents a philosophical shift.
AOT compilation means translating Ruby source code to native machine code *before* execution, producing standalone binaries. This contrasts with Ruby's current execution model where CRuby (MRI) parses source to bytecode and interprets it, with optional JIT compilation happening at runtime.
### The Ruby performance timeline
Ruby's performance story has been a decade-long arc of incremental wins. Ruby 3.0 shipped MJIT (method-based JIT) in 2020. Ruby 3.1 introduced YJIT, Shopify's lazy basic-block versioning JIT, which became the default in Ruby 3.3. YJIT delivered real-world speedups of 15-25% on Rails workloads — meaningful, but not the order-of-magnitude leap that would silence Ruby's performance critics.
TruffleRuby on GraalVM showed what aggressive JIT compilation could do, sometimes matching or beating C on micro-benchmarks, but at the cost of enormous memory overhead and long warmup times that made it impractical for most production Rails deployments.
Spinel attacks from the opposite direction: instead of making Ruby faster at runtime, it eliminates the runtime overhead entirely by compiling ahead of time. This is the same strategy that made Go instantly attractive to a generation of developers who were tired of deploying interpreted language runtimes to production.
### The hard tradeoffs
But here's where it gets genuinely difficult. Ruby's identity is built on dynamism. `method_missing`, `define_method`, `eval`, open classes, monkey-patching — these aren't edge cases, they're the idioms that make Ruby feel like Ruby. Rails itself is a cathedral of metaprogramming.
AOT compilation fundamentally conflicts with these features. When you compile ahead of time, you need to know what methods exist, what classes look like, and what code paths are possible. A language where any object can gain new methods at any point during execution is, to put it technically, a nightmare for static analysis.
This means Spinel almost certainly targets a subset of Ruby — and the interesting question is how large or small that subset turns out to be. Crystal, the compiled language that borrowed Ruby's syntax, answered this question by essentially creating a new language: statically typed, no eval, no reopening classes. Crystal is fast, but it isn't Ruby.
The community discussion on Hacker News reflected this tension. Experienced Rubyists immediately asked about metaprogramming support, dynamic dispatch, and compatibility with existing gems. Others pointed out that a restricted subset of Ruby that compiles to fast native code could be enormously useful even if it can't run Rails — think CLI tools, data processing scripts, serverless functions, and system utilities.
### Where Spinel fits in the landscape
The broader context is that every major dynamic language is grappling with the same question: how do you get compiled-language performance without abandoning the ergonomics that made the language popular?
Python has Cython, Mypyc, Codon, and Nuitka. JavaScript has Bun's native compilation experiments. Each takes a different position on the compatibility-performance spectrum.
Matz building Spinel himself carries weight that a third-party effort wouldn't. It suggests he sees AOT compilation as part of Ruby's official future, not a community side project. Whether Spinel eventually influences CRuby's roadmap, becomes a separate implementation, or remains an experimental sandbox, the directional signal matters.
### If you're running Rails in production
Don't change anything yet. Spinel is early-stage, and Rails' deep metaprogramming makes it an unlikely AOT target in the near term. Continue betting on YJIT, which ships with CRuby and improves with every release. Ruby 3.4's YJIT is genuinely good — if you haven't enabled it, that's your low-hanging fruit.
### If you're building Ruby CLI tools or scripts
This is where Spinel gets interesting fastest. CLI tools don't need the full dynamic runtime. They start, do work, and exit. Ruby's ~100ms startup time is noticeable in CLI contexts where Go and Rust binaries start in single-digit milliseconds. A Ruby subset that compiles to a native binary with instant startup would make Ruby competitive for an entire category of tooling it currently loses to Go.
### If you're evaluating Ruby for new projects
Spinel strengthens the long-term bet on Ruby. The language now has active investment in three distinct performance strategies: interpreter optimization (CRuby core team), JIT compilation (YJIT/Shopify), and AOT native compilation (Spinel/Matz). That's more performance R&D than Ruby has ever had simultaneously.
Watch the repository. Star it if you want to signal demand. But more importantly, look at what subset of Ruby it supports and whether your use case fits within those boundaries.
Spinel is a statement of intent from the person whose intent matters most in Ruby's world. The technical challenges of AOT-compiling a dynamic language are formidable — decades of research on Smalltalk, Self, and JavaScript compilation tell us this — but Matz has never been one to chase impossible goals. If he's building it, he likely has a pragmatic vision for what "compiled Ruby" means that doesn't require solving the general case. The next six months of commits will tell us whether Spinel is a weekend experiment or the beginning of Ruby's next chapter. Given 279 HN points on a repo with no marketing, the community is ready for that chapter to start.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.