← Back to context

Comment by publicdebates

5 hours ago

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.

2 comments

publicdebates

Reply
MyOutfitIsVague  3 hours ago

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);

I'd rather work with Ruby as a language than Lua, but I'd much rather work with Lua than Mruby for the documentation and API alone. If mruby had anything close to the Lua reference documentation, I'd be all over it. As-is, embedding mruby kind of sucks, which is a real shame.