Yes, I'd also love to see JS become "the next step" (since it seems to be becoming the "machine language" of the future) but it would probably have to be augmented like Objective-J to make Cocoa (Touch) development plausible.
I actually hadn't looked too closely at MacRuby. It is quite an achievement, but compared to (particularly) Lua it's just not fast enough. Compare that to LuaJIT and the differences are remarkable. If MacRuby could be made as fast as Lua then I'd be all for it, I just don't think it's possible given the language semantics.
I guess what I'm saying is that the idea of a dynamic language like any of Lua, Ruby, Javascript, etc. . . being the default systems language on iOS and Mac OS would be amazing; I just don't like Ruby's chances when paired against the other two.
Might I suggest that you do so?
...but compared to (particularly) Lua it's just not fast enough.
I beg to differ; Here's why: http://christopherroach.com/2010/01/21/ruby-fibonacci-shooto...
I just don't like Ruby's chances when paired against the other two.
I do. JS might give it a run, with WebKit also being Apple-sponsored. But, there's no Apple-sponsored Lua implementation. And JS from WebKit doesn't have any sort of (easy to use) way to access Cocoa, like MacRuby does (with HotCocoa).
The issue with Ruby is that the things that make it so nice (all of the great object model and meta-programming additions) also bring a certain level of overhead. If it was such a simple task to optimize then the MagLev guys would have produced a kick ass speedy Ruby years ago, based on all of the things that they know about Smalltalk VMs. That said, if Apple has the resources to make MacRuby as fast as Objective C then holy crap; I'd be on that like white on rice.
I don't believe for a moment that Apple would ever use Lua as their systems language of choice; more that I personally thought it would be a great pick. As much as I love Ruby I seriously doubt that Apple would ever be able to squeeze the required performance out of it; the language itself is the problem, not the implementation. Look at all of the work that's gone into producing fast Ruby VMs over the last several years . . . Really, there's low hanging fruit out there and Ruby just doesn't make sense in this context.
Apart from using suboptimal Lua code (the author obviously doesn't know about the Lua keyword 'local'), LuaJIT beta2 didn't compile recursion at all. It runs more than 4x faster with the current version and beats MacRuby easily.
Oh, and comparing language implementations based on the speed of a recursive Fibonacci number generator has exactly zero real-world relevance. Try again with a more realistic mix of benchmarks or something domain-specific like SciMark (LuaJIT is only 30% slower than GCC on this one).
Judging from http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0... MacRuby plays in the same league as the other Ruby implementations. And http://shootout.alioth.debian.org/u32/benchmark.php?test=all... tells you where that league can be found, relative to LuaJIT. Hint: scroll to the bottom. :-)
And when we follow the link to Peter Cooper's comment...
"I decided to give it a go with MacRuby in its regular interpreted mode (which performed well against 1.9.1 in the fib test) and binary-trees gobbled up 3GB of RAM just in the first minute so I cancelled..
pidigits came in at 41.4 seconds on MacRuby (nightly) versus 30.1 seconds for 1.9.1.
On a reduced version of the fannkuck benchmark (using an input of 10 - otherwise it takes a lonnng time to run), MacRuby was 26.038 seconds, 1.9.1 was 24.277 seconds.
So it seems MacRuby being faster than 1.9.1 is hardly a wash at this point, though it shows great potential to eventually beat the 1.9 branch. "