Mruby: Ruby for Embedded Systems
github.com50 points by nateb2022 5 days ago
50 points by nateb2022 5 days ago
IIRC MRuby is also used as the implementation for the DragonRuby game engine[0]
The interesting thing about mruby isn't "Ruby for embedded" as a tagline, it's that it flips the normal embedded tradeoff on its head: you get a dynamic language and a spec, and you treat C as the extension mechanism instead of the other way around.
Most embedded stacks still look like "C all the way down, sprinkle some Lua if you need a scriptable layer". mruby is basically that pattern, but with a much richer standard library, more human-friendly syntax, and a community that thinks in objects instead of state machines. That changes who can work on firmware: you stop needing every feature to be written by the person who understands the MCU reference manual.
Also, the "compile to bytecode, optionally emit C" story matters a lot more in this domain than people realize. In constrained systems, dependency chains kill projects: one more libc quirk, one more weird build flag, one more cross-compiler bug. Having Ruby code become opaque bytecode baked into your image, with a small, well-audited VM around it, is exactly the sort of boundary firmware teams like.
If you squint, mruby is a quiet argument against the idea that embedded has to stay in 1998 forever. Same hardware constraints, but instead of inventing yet another bespoke DSL for each product line, you standardize on a mainstream language and let the VM carry the complexity.
Mruby isn’t aimed at embedded systems, it’s “lightweight Ruby” intended to be embedded within a lower-level application. The language it’s most similar to is Lua.
My gut feeling comparing the two is that mRuby is a better (or at least less “quirky”) language, but Lua has a better (more robust) implementation. I don’t know how the two compare in terms of performance or “lightweight-ness”.
Lua definitely seems to be more widely-used, at least outside Japan.
There's no need to compare to Lua directly, there many similar languages. Notably TCL, or more recently Rhai for Rust.
Agreed. Lua is older though. It was created in 1993.
mruby was created in 2012.
I have only two gripes with regard to mruby.
1) The primary users are C hackers. That's ok, but it means it also leaves out many other people. (Lua has the same problem of course.)
2) Documentation. This is something that really plagues about 90% of ruby projects. And it's not getting any better. It is as if in ruby, only 10% care about documentation - at best. Look at rack, opal, wasm for ruby - the documentation is TOTAL TRASH. Non-existing; look at rack. What a joke.
Now that ruby is following perl in its extinction path (sorry, the numbers are hard and real, there is no way to deny it), the ruby community should instead try to reverse that trend. Instead you see mega-corporations such as shopify pwning the remaining ecosystem and cannibalizing on it or people such as DHH rant about how Europe is collapsing (what the actual ... https://world.hey.com/dhh/europe-is-weak-and-delusional-but-... - we need an alternative to rails, how can anyone still work with DHH? Lo and behold, another shopify guy. The message is so clear for everyone to see now). None of this will of course revitalize ruby. Without an active AND actively growing community, ruby is set to die. I say this as someone who still uses ruby daily; I am tired of the "rumours of ruby dying are exaggerated". Yes, the rumours are exaggerated - but they are not rumours. The numbers are solid. TIOBE alone, with its 10000 faults, shows this trend clearly.
Also worth a mention: mruby/c (https://github.com/mrubyc/mrubyc), which is an even smaller ruby for single-chip microprocessors
/me tips fedora: "m'ruby"
I'm sorry, first thing that came to mind.
The best use case for Mruby I saw is this talk: "Developing your Dreamcast games with mruby"[0] by Yuji Yokoo
I'd like mruby as some kind of fail-save boot system. Ruby powering the operating system as much as possible (ultimately ruby is just syntactic sugar over C, though, so I am fine using C of course).
The lack of documentation means that I'd just waste my time though. Not going to do that.
Also, I think mruby and MRI should not be separate. It doesn't do the project any good. It should be as modular as possible but one code base only.
also possibly interesting to some is the cosmopolitan libc inclusion:
Let's call it Murby :)
I think the name mruby kind of makes sense; we have MRI (matz ruby implementation) so the leading "M" there; we have jruby too. We also have truffleruby which is a bit against that name scheme ... but we could call it truby. Nobody does that, but we could. And MRI could also be called c-ruby. These are not great names though. Murby is also not a great name; it reminds me of Murphy from Robocop though.