Spinel: Ruby AOT Native Compiler • Hacker News Board

Re: Spinel: Ruby AOT Native Compiler

#91

Post by vidarh » Sat, Apr 25, 2026, 9:31 AM UTC

Calavar wrote: post #49

the-lazy-guy wrote: post #22

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.

spinel_codegen.rb is an eldritch horror. I always get spaghetti code like this when using Claude, and I've been wondering if I'm doing something wrong. Now I see an application that looks genuinely interesting (not trivial slop) written by someone I consider to be a top notch programmer, and the code quality is still pretty garbage in some places. For example infer_comparison_type() [1]. This is far from the worst of…

The solution to this with Claude is to use a small agent harness and include refactoring steps once tests are written and pass. For some things you will need to include rules on coding style it should prefer. This is especially true for Ruby or other languages it has not seen as much training data for as for e.g. Python.

Re: Spinel: Ruby AOT Native Compiler

#92

Post by repoinsider » Sun, Apr 26, 2026, 11:37 AM UTC

Interesting that Matz built this in about a month with Claude. The limitations (no eval, no metaprogramming) basically define a 'compilable Ruby subset'.. similar to what mruby does but targeting native executables instead of embedded. The pragmatic approach of generating C rather than LLVM IR makes sense for a first version you get portability and debuggability for free.

Re: Spinel: Ruby AOT Native Compiler

#93

Post by xp84 » Mon, Apr 27, 2026, 5:28 AM UTC

Calavar wrote: post #82

xp84 wrote: post #65

Earlier quoted context omitted.

> Quite a lot, that's what allows you to build something like Rails with magic sprinkled all around True, but I'd point out that use in frameworks/DSLs etc is the main place you see those things, and most of the code people write in their own projects don't use these. In my experience (YMMV), eval and send are rare outside of things like, slightly cowboy unit tests (send basically lets you call private methods that y…

I disagree, I use metaprogramming in application code quite regularly, although I tend to limit myself to a single construct (instance_eval) because I find that makes things more manageable. In my opinion the main draw of Ruby is that it's kind of Lisp-y in the way you can quickly build a metalanguage tailored to your specific problem domain. For problems where I don't need metaprogramming, I'd rather use a language…

I don't think instance_eval is too nasty. The toughest "good" codebase I've worked in was difficult because it used method_missing magic everywhere, which built tons of methods whose existence you had to just infer, based on configuration stored in a database. So most method calls could not be "command clicked" or whatever to jump to their definition, because none were ever defined.