Mruby: Ruby for Embedded Systems(github.com)
github.com
Mruby: Ruby for Embedded Systems
https://github.com/mruby/mruby
40 comments
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.
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 MRuby embedding API isn't a whole lot like Lua's. Lua is a fantastic experience to embed. You might have to futz with the registry to store Lua objects in a C struct, but the abstraction allows you to almost never have to actually worry about the VM internals or the GC directly. Mruby is a lot more like MRI Ruby's API. Raw objects are exposed to you, you have to turn off strict aliasing because inheritance is implemented by the old "common meta struct as first member" idiom, you have to manually trigger VM collecting in long-running C code ( https://github.com/mruby/mruby/blob/master/doc/guides/gc-are... ), getting args in a C function involves a variadic scanf-style function. The most striking difference is documentation. The documentation of the mruby C API is actually "read the headers". There are many seemingly redundant functions that look like they do the same thing, completely without explanatory comments, or minimal inscrutable comments:
/* mrb_gc_protect() leaves the object in the arena */
MRB_API void mrb_gc_protect(mrb_state *mrb, mrb_value obj);
/* mrb_gc_register() keeps the object from GC. */
MRB_API void mrb_gc_register(mrb_state *mrb, mrb_value obj);
/* mrb_gc_unregister() removes the object from GC root. */
MRB_API void mrb_gc_unregister(mrb_state *mrb, mrb_value obj);
> you have to turn off strict aliasing because inheritance is implemented by the old "common meta struct as first member" idiom
You shouldn't have to turn off strict aliasing for that, struct pointers are allowed to alias pointers to their first member. Unless I'm missing some awkward compatibility rule that mruby breaks.
You shouldn't have to turn off strict aliasing for that, struct pointers are allowed to alias pointers to their first member. Unless I'm missing some awkward compatibility rule that mruby breaks.
You do need to turn off strict aliasing for that, because mruby uses `struct RObject { RB_OBJECT_HEADER; ... }` and `struct RHash { MRB_OBJECT_HEADER; ... }` (where MRB_OBJECT_HEADER begins with `RClass `). You can alias objects of both types as an `RClass `, but you can't alias them as one-another, converting RHash to RObject. According to my reading of the strict aliasing rules[0], the aliasing would be legal if one of the types literally contained the other, or if they were being accessed through a union. The "compatible types"[0] section requires the types to be exactly the same in layout, not just starting as the same. It's not safe to cast incompatible structs to one another just because they have the same initial members, unless you are accessing them through a union (C11 6.5.2.3p6). Optimization can cause UB when working with mruby if strict aliasing is enabled.
[0] https://en.cppreference.com/w/c/language/object.html#Strict_... [1] https://en.cppreference.com/w/c/language/compatible_type.htm...
[0] https://en.cppreference.com/w/c/language/object.html#Strict_... [1] https://en.cppreference.com/w/c/language/compatible_type.htm...
Oof, I get it now. I was expecting RHash to start with an actual RObject, not just the same members. I too read the "compatible first member" rule as not applying here, so I agree it breaks strict aliasing.
There are Javascript to Lua compilers, used by Roblox programmers.
And moonscript, which does a decent job as well
There's no need to compare to Lua directly, there many similar languages. Notably TCL, or more recently Rhai for Rust.
how is Lua quirky? I've looked at it once and I didn't see anything that I thought was weird, although that was on the syntactical level.
Syntactically: From `~=` instead of `!=`, and no support for `+=` or `continue`, to free-form syntax with no statement separators - except in that one place where they're necessary.
Semantically: Conflation of arrays and maps, conflation of `nil` and empty (both in tables and in function arguments), and the perennially-unpopular 1-based indexing.
Semantically: Conflation of arrays and maps, conflation of `nil` and empty (both in tables and in function arguments), and the perennially-unpopular 1-based indexing.
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.
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.
Ruby was used in Japan before Rails appeared, and it will continue to be used after Rails dies.
It's genuinely wild how many times people feel the need to declare that Ruby is dead.
If our competitors voluntarily choose to use tools that are demonstrably less productive, that's great news for us.
So yes: Ruby is totally dead. No question. Without a doubt.
If our competitors voluntarily choose to use tools that are demonstrably less productive, that's great news for us.
So yes: Ruby is totally dead. No question. Without a doubt.
Hanami remains a bright spark as an alternative growing Ruby app framework to Rails. The project is under active development, I’ve met the core dev and they are lovely and much more humble than DHH and the project aims to stick much closer to the Ruby ways of doing things as opposed to the rails way.
Sure the project just can’t be as mature as Rails but it deserves a look and we need to get behind projects like this if we do indeed want to see Rails alternatives flourish and grow.
https://hanamirb.org/
Sure the project just can’t be as mature as Rails but it deserves a look and we need to get behind projects like this if we do indeed want to see Rails alternatives flourish and grow.
https://hanamirb.org/
> 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.
Are you familiar with the Ruby ecosystem?
You can easily view documentation for all installed gems using yard like so:
Are you familiar with the Ruby ecosystem?
You can easily view documentation for all installed gems using yard like so:
yard server --gems
yri Rack::Request
yri Rack::Response#set_cookie> look at rack. What a joke.
Yeah, I think the Ruby world burned out of the whole "make everything nice" aesthetic when they alienated the everloving fuck out of _why. Now it's a post-apocalyptic wasteland where if you want nice things, you better be prepared to become a right expert because you will have no one to turn to when it breaks. I don't mind, I don't make money coding anymore and the challenge makes me feel alive again.
If I ever get to the point to where I gotta learn the C API, I'll do it through mruby. But it'll be a much easier path to systems work to interop with Rust instead.
Yeah, I think the Ruby world burned out of the whole "make everything nice" aesthetic when they alienated the everloving fuck out of _why. Now it's a post-apocalyptic wasteland where if you want nice things, you better be prepared to become a right expert because you will have no one to turn to when it breaks. I don't mind, I don't make money coding anymore and the challenge makes me feel alive again.
If I ever get to the point to where I gotta learn the C API, I'll do it through mruby. But it'll be a much easier path to systems work to interop with Rust instead.
The best use case for Mruby I saw is this talk: "Developing your Dreamcast games with mruby"[0] by Yuji Yokoo
[0]: https://m.youtube.com/watch?v=ni-1x5Esa_o
[0]: https://m.youtube.com/watch?v=ni-1x5Esa_o
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.
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 know both C and Ruby, and Ruby is far more than syntactic sugar over C.
Like not even close.
Like not even close.
Also worth a mention: mruby/c (https://github.com/mrubyc/mrubyc), which is an even smaller ruby for single-chip microprocessors
IIRC MRuby is also used as the implementation for the DragonRuby game engine[0]
[0] https://dragonruby.org/
[0] https://dragonruby.org/
Previous discussions:
April 2012 (55 comments, 174 points): https://news.ycombinator.com/item?id=3866555
April 2012 (55 comments, 174 points): https://news.ycombinator.com/item?id=3866555
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:
https://www.youtube.com/watch?v=WiJC_v5Lus8 https://picoruby.org/
https://www.youtube.com/watch?v=WiJC_v5Lus8 https://picoruby.org/
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.
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.
For dotnet, there is a built-in flag "--self-contained".
For Java, there is a built-in command: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa...
This feature alone is a reason why I in some occasions use MRuby, when I have a Ruby script I want to share as standalone binary. I sometimes don't even have to rewrite anything, it just works.
also possibly interesting to some is the cosmopolitan libc inclusion:
https://github.com/mruby/mruby/pull/6681
https://github.com/mruby/mruby/pull/6681
[deleted]
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.
Mruby was a good attempt but I don't think they have become a competitive options.
[deleted]
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.
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.
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.
/me tips fedora: "m'ruby"
I'm sorry, first thing that came to mind.
I'm sorry, first thing that came to mind.
Looking for a good tutorial about Visual Basic for Real time rocket guidance, any repo you can recommend?
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.