Spinel: Ruby AOT Native Compiler • Hacker News Board

Re: Spinel: Ruby AOT Native Compiler

#21

Post by psychoslave » Fri, Apr 24, 2026, 12:03 PM UTC

vidarh wrote: post #13

whizzter wrote: post #2

If it wasn't built by Matz I'd have severe doubts, but it's clearly defined and I presume he knows all limitations of the Ruby semantics well. My thesis work (back when EcmaScript 5 was new) was an AOT JS compiler, it worked but there was limitations with regards to input data that made me abandon it after that since JS developers overall didn't seem to aware of how to restrict oneself properly (JSON.parse is inheren…

> If it wasn't built by Matz I'd have severe doubts, but it's clearly defined and I presume he knows all limitations of the Ruby semantics well. It's a very pragmatic design: Uses Prism - parsing Ruby is almost harder than the actual translation - and generates C. Basic Ruby semantics are not all that hard to implement. On the other extreme, I have a long-languishing, buggy, pure-Ruby AOT compiler for Ruby, and I mad…

Didn’t Ruby already embedded GCC at some point with similar ideas in mind?

Re: Spinel: Ruby AOT Native Compiler

#22

Post by the-lazy-guy » Fri, Apr 24, 2026, 12:06 PM UTC

While obviously super-impressive, it is clearly not maintanable without AI agent. It has spinel_codegen.rb is 21k lines of code with up to 15 levels of nesting in some methods.

Compilers code was never pretty, but even by those standard, I feel like it is a very-very hard to maintain code by humans.

Re: Spinel: Ruby AOT Native Compiler

#23

Post by vidarh » Fri, Apr 24, 2026, 12:12 PM UTC

psychoslave wrote: post #21

vidarh wrote: post #13

Earlier quoted context omitted.

> If it wasn't built by Matz I'd have severe doubts, but it's clearly defined and I presume he knows all limitations of the Ruby semantics well. It's a very pragmatic design: Uses Prism - parsing Ruby is almost harder than the actual translation - and generates C. Basic Ruby semantics are not all that hard to implement. On the other extreme, I have a long-languishing, buggy, pure-Ruby AOT compiler for Ruby, and I mad…

Didn’t Ruby already embedded GCC at some point with similar ideas in mind?

Not embedding them, but mjit generated C and used a C compiler to compile it:

https://www.heroku.com/blog/ruby-mjit/#mjit

Re: Spinel: Ruby AOT Native Compiler

#24

Post by pjmlp » Fri, Apr 24, 2026, 12:15 PM UTC

xz18r wrote: post #4

Given it's built by Matz, how realistic is it that this becomes a core part of Ruby? And if so, how threatening is that for Crystal?

This should be seen in another perspective, we will eventually reach the point where LLMs can vomit the formal specification in whatever language we feel like.

The revenge of Rational Unified Process, Enterprise Architect and many other tools.

Instead of UML diagrams it is markdown files.

Re: Spinel: Ruby AOT Native Compiler

#25

Post by Someone » Fri, Apr 24, 2026, 12:37 PM UTC

Limitations

- No eval: eval, instance_eval, class_eval

- No metaprogramming: send, method_missing, define_method (dynamic)

- No threads: Thread, Mutex (Fiber is supported)

- No encoding: assumes UTF-8/ASCII

- No general lambda calculus: deeply nested -> x { } with [] calls

Assuming UTF-8/ASCII isn’t, IMO, a huge limitation, but some of the others likely are, for quite a few programs. Removing them also will require serious work, I think.

Re: Spinel: Ruby AOT Native Compiler

#26

Post by drzaiusx11 » Fri, Apr 24, 2026, 1:01 PM UTC

Curious why "no threads" when the ruby scheduler and underlying pthread implementation should work fine in C land. I guess to be "zero dependency"? Seems an odd trade-off to me, unless optional "extensions" are planned / omitted for later implementation etc.

Re: Spinel: Ruby AOT Native Compiler

#27

Post by rayiner » Fri, Apr 24, 2026, 1:01 PM UTC

dluan wrote: post #10

For some context, just presented by Matz at RubyKaigi 2026. It’s experimental but he built it with help from Claude in about a month. Successful live demo. It’s named after his new cat, which is named after a cat in Card Captor Sakura, which is the partner to another character named Ruby.

> It’s experimental but he built it with help from Claude in about a month.

We talk a lot about AI building programs from soup to nuts. But I think people overlook the more likely scenario. AI will turn 10x programmers into 100x programmers. Or in Matz’s case maybe 100x programmers into 500x programmers.

Re: Spinel: Ruby AOT Native Compiler

#28

Post by modernerd » Fri, Apr 24, 2026, 1:03 PM UTC

dluan wrote: post #10

For some context, just presented by Matz at RubyKaigi 2026. It’s experimental but he built it with help from Claude in about a month. Successful live demo. It’s named after his new cat, which is named after a cat in Card Captor Sakura, which is the partner to another character named Ruby.

Thanks! Video doesn't seem to be live yet but they seem to be dripping them out here:

https://www.youtube.com/@rubykaigi4884/videos

Re: Spinel: Ruby AOT Native Compiler

#29

Post by throwaway041207 » Fri, Apr 24, 2026, 1:20 PM UTC

> No eval: eval, instance_eval, class_eval

> No metaprogramming: send, method_missing, define_method (dynamic)

> No threads: Thread, Mutex (Fiber is supported)

Speaking as someone who has written a lot of Ruby code over the years, utilizing every single one of these features of Ruby, I have to say this is the version of Ruby I've evolved to want: simpler and easier to understand but with the aesthetic beauty of Ruby intact.

IMO this more limited variant of Ruby is more practical now that we have extremely productive code generation tools in the form of LLMs. A lot of meta-programming ostensibly exists to make developers more productive by reducing the amount of boilerplate code that has to be written, but that seems no longer necessary now that developers aren't writing code.

Re: Spinel: Ruby AOT Native Compiler

#30

Post by satvikpendem » Fri, Apr 24, 2026, 1:30 PM UTC

throwaway041207 wrote: post #29

> No eval: eval, instance_eval, class_eval > No metaprogramming: send, method_missing, define_method (dynamic) > No threads: Thread, Mutex (Fiber is supported) Speaking as someone who has written a lot of Ruby code over the years, utilizing every single one of these features of Ruby, I have to say this is the version of Ruby I've evolved to want: simpler and easier to understand but with the aesthetic beauty of Ruby…

What about Crystal? If it's just the aesthetic beauty you want then it might be a good fit as it's similar syntax yet statically typed which leads into more efficient compiled code.