It's meant to be a minimized version of Ruby. Not full-featured, just the bare essentials and meant to be able to run on embedded devices/phones. To do so, mRuby will need to be much smaller than standard Ruby and much faster.
I have quite some experience with Lua scripting and embedding. Honestly, I can't see any other language taking that throne any time soon. For all its quirks, Lua is an amazingly powerful language that was designed from the ground up for embeddability.
You know, you can replace Lua's memory allocator with your own by overwriting one simple function. Your platform does not support double? Lua has you covered: Change one define, and Lua uses short as its numeric data type. Since it is all ANSI C, this enables you to run Lua on a fixed-point signal processor if you must.
And then there is memory consumption and execution speed. Can you fit Ruby in 150k? Lua fits just fine, including its (small) standard library. Also, it is insanely easy to embed into your C codebase. Basically, it is one include and one struct you have to carry around and you are all set.
At the 2nd Ruby conference there was a general discussion (with all 100 or so attendees :) ) about Ruby's future and where it might find its killer app.
I openly wondered if it would be Web development. Mind you, this was in 2002; while there were some good Ruby Web frameworks (I think Avi Bryant gave a talk on Seaside and using Ruby continuations in a Web framework) we had yet to see the likes of Nitro or Rails poke through to show how crazy easy Ruby could make it.
The general response was, No, PHP and Perl have a lock on that, Ruby will need to find some other niche.
Obviously PHP and Perl are still used for Web development, but you don't need to completely dominate an area to be effective. Just be good enough for enough people.
As tech changes what makes something a good fit now may not apply later. Size and speed are important, but as things get faster and more hardware more robust you no longer be quite as fast or quite as small. Just fast enough and small enough and good enough.
Good question. I'm going to try to answer it for embedding a scripting language into your existing code base.
I'm going to presume that your code base is written in something relatively low-level because otherwise you would not need to embed a scripting language. Hence, your application probably has some performance demands. Obviously you expect your scripting system to be slower, but not dog slow. While Lua is quite a bit faster than Ruby, both are orders of magnitude slower than C code, so I don't really see this as a problem in most cases.
Common tasks for an embedded language might be configuring some part of your application. For that, the embedded language does not need to be particularly fast or small. It only needs to have convenient ways of creating data structures and a simple C-API. I would wager that the C API of Lua is about as simple as it gets and it is absolutely trivial to embed it into your program. I would say that Ruby needs to catch up a bit to be useful here.
Another typical application is to write non performance-critical but complicated code in a nicer language. This usually evolves pretty quickly into some kind of specialized DSL. Hence, you need a language with rich metaprogramming capabilities. In my limited experience with metaprogramming in Ruby I have found it to be amazingly powerful (if somewhat hard to grasp). On the other hand, I would say that the absence of a built-in object system in Lua does count as a benefit here, since rolling your own hand-tailored object system that perfectly suits your DSL needs is relatively simple. In the end though, many more people know Ruby syntax than Lua syntax, so I could see a future for Ruby here.
Still, I don't really see Ruby and Lua in the same ballpark here. Lua is designed from ground up for embedding. As a result it is really fast, very small and extremely easy to embed.
Ruby is a proper general-purpose programming language in its own right. Even though mruby is going quite far to make it small and simple, it will never compete with something that was purposely built for that. On the other hand, Lua will never compete with Ruby in terms of library support and rich syntax.
7 comments
[ 3.9 ms ] story [ 11.8 ms ] threadDoes that just mean a smaller standard library?
"mRuby will need to be much smaller than standard Ruby and much faster"
Right. I'm looking forward to the mruby authors (or someone else skilled at interpreter design) writing up how that is being accomplished.
You know, you can replace Lua's memory allocator with your own by overwriting one simple function. Your platform does not support double? Lua has you covered: Change one define, and Lua uses short as its numeric data type. Since it is all ANSI C, this enables you to run Lua on a fixed-point signal processor if you must.
And then there is memory consumption and execution speed. Can you fit Ruby in 150k? Lua fits just fine, including its (small) standard library. Also, it is insanely easy to embed into your C codebase. Basically, it is one include and one struct you have to carry around and you are all set.
For embedding, Lua is just awesome!
I openly wondered if it would be Web development. Mind you, this was in 2002; while there were some good Ruby Web frameworks (I think Avi Bryant gave a talk on Seaside and using Ruby continuations in a Web framework) we had yet to see the likes of Nitro or Rails poke through to show how crazy easy Ruby could make it.
The general response was, No, PHP and Perl have a lock on that, Ruby will need to find some other niche.
Obviously PHP and Perl are still used for Web development, but you don't need to completely dominate an area to be effective. Just be good enough for enough people.
As tech changes what makes something a good fit now may not apply later. Size and speed are important, but as things get faster and more hardware more robust you no longer be quite as fast or quite as small. Just fast enough and small enough and good enough.
I'm going to presume that your code base is written in something relatively low-level because otherwise you would not need to embed a scripting language. Hence, your application probably has some performance demands. Obviously you expect your scripting system to be slower, but not dog slow. While Lua is quite a bit faster than Ruby, both are orders of magnitude slower than C code, so I don't really see this as a problem in most cases.
Common tasks for an embedded language might be configuring some part of your application. For that, the embedded language does not need to be particularly fast or small. It only needs to have convenient ways of creating data structures and a simple C-API. I would wager that the C API of Lua is about as simple as it gets and it is absolutely trivial to embed it into your program. I would say that Ruby needs to catch up a bit to be useful here.
Another typical application is to write non performance-critical but complicated code in a nicer language. This usually evolves pretty quickly into some kind of specialized DSL. Hence, you need a language with rich metaprogramming capabilities. In my limited experience with metaprogramming in Ruby I have found it to be amazingly powerful (if somewhat hard to grasp). On the other hand, I would say that the absence of a built-in object system in Lua does count as a benefit here, since rolling your own hand-tailored object system that perfectly suits your DSL needs is relatively simple. In the end though, many more people know Ruby syntax than Lua syntax, so I could see a future for Ruby here.
Still, I don't really see Ruby and Lua in the same ballpark here. Lua is designed from ground up for embedding. As a result it is really fast, very small and extremely easy to embed.
Ruby is a proper general-purpose programming language in its own right. Even though mruby is going quite far to make it small and simple, it will never compete with something that was purposely built for that. On the other hand, Lua will never compete with Ruby in terms of library support and rich syntax.