Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Why MacRuby Matters (Present & Future) (antoniocangiano.com)
29 points by acangiano on March 29, 2009 | hide | past | favorite | 14 comments


I have to agree with Nutter - MacRuby is nowhere near a complete implementation and there is absolutely no point trying to judge its performance until it is. See last year's MagLev debacle for precedent. You were right on board with that train wreck, if I recall correctly, and let me assure you the few of us who poured skepticism on their numbers are feeling pretty vindicated by now.

Another problem I have is the use of these artificial benchmarks to judge speed at all. Time and time again experience has shown that benchmark performance has little relevance in the real world. For example, your most recent Ruby 1.9 benchmarks post:

http://antoniocangiano.com/2008/12/10/reflections-on-the-rub...

shows Ruby 1.9 coming out 250% faster than 1.8. 250%! This is an absolutely meaningless figure. I have recently posted my own benchmarks of actual production 1.8.6 and 1.9.1 installations running an actual real world program (Rails) serving an actual production web site and the performance gain is closer to 15%:

http://fukamachi.org/wp/2009/03/27/thin-ruby-191-vs-ruby-186...

I will not pretend that my quick and dirty testing is any kind of canonical "last word" result but on the other hand, I also can say with absolute certainty that no sizable app is going to experience anywhere near a 250% speed increase from Ruby 1.9. These benchmarks are worse than nothing, they're completely misleading. I am all for getting everyone onto 1.9 but geeze!

And of course you can't even run a "real world" app on MacRuby at all, because it's too immature, which kind of completes the circle of pointlessness. It is way too early for this kind of thing.

I do sympathise with your mission of promoting knowledge of and getting people excited about the future of the various Ruby implementations but can you please tone back the hype a bit?


Also see http://blog.headius.com/2009/03/on-benchmarking.html for the other side of this story


From http://maglev.gemstone.com/status/

"MagLev swings from being much faster than MRI to being much slower". We're focused on RubySpec compliance for now, and will address performance later this year.

It's in a private alpha test, so I guess we'll see.

MacRuby is interesting because Apple has a new platform for OS X and the Obj-C runtime, and they're selling them like hotcakes. You have your Webkit window with Ruby locally, talking to some servers remotely if necessary, and the desktop app / web app just gets a lot more interesting.


It's been in private alpha test for a long time now, and yet they hyped it up a year ago with insane performance claims (50x faster than MRI!). I'm glad to hear they are "focused on RubySpec compliance". However, the whole reason people got upset last year was that until it's at least usably compliant, it's not Ruby.

Their compliance graph looks encouraging, though, hopefully we'll see some proper tests soon.

Yeah, I've been playing with the new release of MacRuby all weekend and it is great. And it's embeddable, too! The possibilities are incredible. Don't get me wrong, I love MacRuby, I just think Antonio's benchmarking process is flawed.


This is predicated on the assumption that Ruby matters, present & future.

While I love Ruby, and use it for most code I don't write in Javascript, I can't help but wonder if in 10 years' time Ruby will look as big and bloated and arcane as Perl does now, and some new upstart will have all the mindshare.


You say that like it's a bad thing!

If there was a viable young upstart which was better enough to seriously start stealing Rubyists away (perhaps a "Ruby for functional programming"?) then wouldn't that be a net gain for the world?

I love Ruby but I hope it's irrelevant in 10 years' time, because we've all moved onto something unambiguously better. Think of how much more productive we'll be! : )


Alan Kay, in his Turing award lecture:

A couple of years ago we started this project called Squeak, which is simply not an attempt to give the world a free Smalltalk, but an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk, and when you fool around with Squeak, please, please, think of it from that standpoint. Think of how you can obsolete the damn thing by using its own mechanisms for getting the next version of itself.


Inspiring words from a great man!

I think the concept of code generation is yet to sink in to the mainstream programming world, but one might expect it to have a huge impact when it does. Especially in the emerging world of distributed programming.


While I love Ruby, and use it for most code I don't write in Javascript, I can't help but wonder if in 10 years' time Ruby will look as big and bloated and arcane as Perl does now, and some new upstart will have all the mindshare.

That has no relevance to the present. That's like the argument against upgrading your computer because the parts you buy will be outperformed by newer parts on the horizon. Eventually you have to settle for a while, and plenty of people are settled on Ruby for now.


On the other hand, in ten years there might be something similar to CPAN and less complaints about lack of speed and memory leaks... :-)


I am not qualified to comment on the speed issues, but I don't want to loose sight of how very cool MacRuby is, even if it is slower than YARV/JRUBY. Imagine taking Ruby to the Iphone. Too cool......


But Objective C is pretty nice too and with blocks being added to it, is there any reason to want Ruby (other than personal preference) on the iPhone. They should have had it from day 1 of course.


If you consider Obj-C and Ruby interchangeable, you haven't programmed in at least one of them.


Both and I have done Smalltalk so I know exactly what blocks should look like (and it is not what it is in Ruby).

Maybe you should verify your assertion again.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: