61–70 of 93 posts
Earlier quoted context omitted.
It seems like a compiler from Ruby to Objective C could support all the Ruby features while still being more performant than interpreted Ruby.
there was MacRuby[0] which I seem to remember had an AoT compiler and was built on the ObjC foundation but was later abandoned. [0] https://en.wikipedia.org/wiki/MacRuby
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.
But since writing code is very easy now with AI I write better code because it doesn't take me more time and effort.
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.
The problem is that people often do not have the time to refactor once they have gotten the thing to work. And the mess keeps growing.
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. 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…
> eval, send, method_missing, define_method , as a non-rubyist how common are these in real-world code? Quite a lot, that's what allows you to build something like Rails with magic sprinkled all around. I'm not 100% sure, but probably the untyped JSON ingestion example uses those. Remove that, and you have a very compact and readable language that is less strongly typed than Crystal but less metaprogrammable than off…
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 you shouldn't be able to call, so it's considered terrible form to use it 'IRL'. Though there is a public_send which is a non-boundary-violating version too).
Also in my opinion, unless you're developing a framework or something, metaprogramming (things like define_method etc) are Considered Harmful 95% of the time (at least in Ruby), as I think only about 5% of Ruby developers even grok it enough to work in a codebase with that going on. So while it might seem clever to a Staff Eng with 15 years of Ruby experience, the less experienced Rubyist who is going to be trying to maintain the application later is going to be in pain the whole time due to not being able to find any of the method definitions that appear to be being called.
I will eat the downvotes to say what I actually think. Unless this gets back eval, metaprogramming and threads this isn't all that interesting as an actual language. There are plenty of compiled languages out there. Metaprogramming is what makes Ruby interesting and expressive. I know that this is just an experiment, but I've seen plenty of cases where stuff exactly like this gets forced into use in production becaus…
Spinel would be more interesting if this compiled subset could run side by side with interpreted Ruby, like Pallene does for (slightly modified) Lua.
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…
The interesting bunch (to me, based on experience) is `eval`, `exec`, and `define_method` (as well as creating new classes with `Class.new` `Struct.new`). My sense is that the majority of their use is at the time of application boot, while requiring files. In some ways, it is nearly a compilation step already.
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…
It seems like a compiler from Ruby to Objective C could support all the Ruby features while still being more performant than interpreted Ruby.
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.
The most recent cartoon Spinel in my mind is from Steven Universe, so I hadn't noticed the Spinel/Ruby (Moon) pun, that made my day.
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…
> eval, send, method_missing, define_method , as a non-rubyist how common are these in real-world code This depends on the individual writing code. Some use it more than others. I can only give my use case. .send() I use a lot. I feel that it is simple to understand - you simply invoke a specific method here. Of course people can just use .method_name() instead (usually without the () in ruby), but sometimes you may…
It's not to be beholden to types per-se, but rather that fixed types are way faster to execute since they map to basic CPU instructions rather than operations having to first determine the type and then branch depending on the type used.
The problem with dynamic types is that they either need to somehow join into fixed types (like with TypeScript specifying a type-specification of the parsed object) or remain dynamic through execution (thus costing performance).