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.
I've used Ruby and Lua for about 15 years now, and looked at mruby (and possibly used it, I don't remember) about 10 years ago. Having little else to contribute to society anymore, perhaps my insight on these two languages might be of some use to some.
IIrc, Matz designed Ruby as a pet passion project, and its design was reactionary against excessiveness found in other languages, hence its minimalism in arguably excessive syntax and notation. Otoh, Tegcraf designed Lua out of pure necessity, adding only the features needed to satisfy its clients' needs.
In my opinion, necessity always leads to the better product than desire, hence C is still unbeat, having been formed under similar circumstances. Lua's C API is copied by nearly every other embeddable scripting language, including (I think) mruby. Yet they were the first to come up with it, a testament to their creativity under pressure.
Ruby (and mruby) takes the Smalltalk approach, and asks, what if everything was an object and every function call is a method call? Lua takes a less extreme approach, and merely asks, what if every data structure was built on a hashmap?
Other than that, Lua takes a very minimal approach, having break/goto but not continue, if/elseif but not switch, metamethods but not inheritance. It gets to 90% of the functionality of JavaScript with 10% of the spec and 1% of the code. You can read the entire Lua manual in one Saturday. You can read its grammar in under five minutes.
For all its cleverness, and as a price for its concise implementation and design, Lua is inconvenient to use. Hence the plethora of languages that compile to Lua and try to make it more convenient to use. One comes to mind but I can't remember or google the name successfully.
The one thing I like the most about mruby is the way you can ship apps.
When you normally want to ship apps which are written in Java, C#, python etc. you have to tell your users they have to download that runtime and your deps and how to start the runtime and which args to start your app from the command line.
With mruby you can just ship one file and everything is self contained.
Noteworthy in the MRuby universe, which is all about lightweight Ruby implementations is picoruby. You can get an integrated ruby shell on a Raspberry Pi Pico:
I love Ruby and have tried to use mruby several times, but the one thing that always becomes an issue is that it uses Ruby’s own native-extension build system for compilation, which is configured in Ruby itself. It makes it a total pain to include in other build systems, or when compiling to other targets (i.e. WASM)
Frankly, I love Ruby as a language, but if it were as easy to embed as Lua I would have no reason to use Lua.
I believe even in Japan Lua is more popular because of the reasons mentioned in other threads. When I worked at a game studio there Lua was the script engine of the choice, mostly because other companies are also using it and there was a tribal knowledge of the language.
Mruby was a good attempt but I don't think they have become a competitive options.
18 comments
[ 31.6 ms ] story [ 373 ms ] thread[0]: https://m.youtube.com/watch?v=ni-1x5Esa_o
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.
IIrc, Matz designed Ruby as a pet passion project, and its design was reactionary against excessiveness found in other languages, hence its minimalism in arguably excessive syntax and notation. Otoh, Tegcraf designed Lua out of pure necessity, adding only the features needed to satisfy its clients' needs.
In my opinion, necessity always leads to the better product than desire, hence C is still unbeat, having been formed under similar circumstances. Lua's C API is copied by nearly every other embeddable scripting language, including (I think) mruby. Yet they were the first to come up with it, a testament to their creativity under pressure.
Ruby (and mruby) takes the Smalltalk approach, and asks, what if everything was an object and every function call is a method call? Lua takes a less extreme approach, and merely asks, what if every data structure was built on a hashmap?
Other than that, Lua takes a very minimal approach, having break/goto but not continue, if/elseif but not switch, metamethods but not inheritance. It gets to 90% of the functionality of JavaScript with 10% of the spec and 1% of the code. You can read the entire Lua manual in one Saturday. You can read its grammar in under five minutes.
For all its cleverness, and as a price for its concise implementation and design, Lua is inconvenient to use. Hence the plethora of languages that compile to Lua and try to make it more convenient to use. One comes to mind but I can't remember or google the name successfully.
https://github.com/mruby/mruby/pull/6681
I'm sorry, first thing that came to mind.
[0] https://dragonruby.org/
When you normally want to ship apps which are written in Java, C#, python etc. you have to tell your users they have to download that runtime and your deps and how to start the runtime and which args to start your app from the command line.
With mruby you can just ship one file and everything is self contained.
April 2012 (55 comments, 174 points): https://news.ycombinator.com/item?id=3866555
https://www.youtube.com/watch?v=WiJC_v5Lus8 https://picoruby.org/
Frankly, I love Ruby as a language, but if it were as easy to embed as Lua I would have no reason to use Lua.
Mruby was a good attempt but I don't think they have become a competitive options.