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.
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.
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.
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.
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.
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.
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.
[0] https://dragonruby.org/
I'm sorry, first thing that came to mind.
[0]: https://m.youtube.com/watch?v=ni-1x5Esa_o
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.
https://github.com/mruby/mruby/pull/6681