MacRuby 0.6 Official Release | Hacker News Reader

MacRuby 0.6 Official Release

macruby.org

64 pointssant0sk121 comments

"In this release, we believe that MacRuby is now stable enough to consider using it to develop Cocoa applications."

"This release also passes about 85% of RubySpecs..."

Those two things seemed a little contradictory to me at first. But then I noticed the part about macruby apps being able to compile to machine code, so I guess what they mean is that if your app is stable in macruby, it will be stable when you ship it, even macruby isn't fully compatible with ruby yet.

Definitely looking forward to playing around with it.

Ruby the language is pretty gigantic, so there are a lot of hard-to-fix corner cases. IronRuby, IIRC, passes 85% or so and just hit 1.0 and can run Rails. So most Ruby you write will run on this, but it is possible to break it.

well... just because 85% of Ruby runs, doesn't mean that 85% of your usecases are covered. Unfortunately for me, a variety of rubygems that my apps and libs depend on break with 0.6, even things as lightweight as Addressable.

Still lookin' forward to more macruby though :)

I'm still waiting for the MacRuby/GCD Rack-compatible webserver they mentioned awhile ago, supposedly called "ControlTower".

It's available in the svn repo.

True, but you probably want to wait for the official announcement. There's a decent amount of churn at the moment...

I'm having a hard time finding it, can you point me to it?

Nice, I am curious how it will benchmark against Ruby 1.9.1 for some of my libraries. Anyone run any benchmarks yet on their code?

I am dissapointed: tried running it on a utility I wrote for crunching Wikipedia text (lots of string operations, some file IO) and it is so much slower than Ruby 1.9.1. I stopped the benchmark after 5 minutes (same test took about 70 seconds with Ruby 1.9.1). Then I tried a simple string manipulation benchmark, and it ran about 3 times slower in MacRuby.

Using Cocoa classes in MacRuby is great for Mac development but (apparently) really slows down string operations.

As I understand it, the focus up 'til now has been correctness and compatibility rather than performance / efficiency. It seems a bit early to jump on them for that (though the speed hit you mention is surprising). That said, I'd expect things to pick up speed once the next-generation compiler Laurent mentions in the blog post is ready (and when the RubySpec needle moves closer to 100).

Regardless, the team has made a ton of progress since the last release. Here's looking forward to the next.

There has been work on performance; in a lot of cases, MacRuby is faster than YARV. Just, not in this case, with strings. Thats mostly because strings were just redone to use NSString's internally, so there hasn't been as much work done on them as there has in other parts.

Look back on how JRuby developed. At first the concerns were to make sure you could simply run Ruby code. But over time that became a given, and speed became the new focus. They've done quite well and I expect the MacRuby team to do so as also.

I'm going to publish a Ruby shootout on Mac very soon.

Great. Looking forward to that.

Published: http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0...

Does anyone know how this differs from the Ruby that is a native part of OS X 10.6? Is it just a newer version?

  MomBook:~ hackermom$ ruby -v
  ruby 1.8.7 (2009-06-08 patchlevel 173) [universal-darwin10.0]

It uses the Objective-C runtime, including "native" objects (strings are NSStrings, hashes are NSDictionaries, etc.). It generates native code (using LLVM) rather than interpreting. It has a more sensible syntax for making Objective-C method calls. (And more.)

Also might be worth noting: MacRuby is an implementation of Ruby 1.9, not 1.8.x. Any benchmarks done should be compared against YARV, not what comes with OS X.

yes. and hotcocoa is a wrapper for cocoa that is more rubyish for making native cocoa apps in ruby.

Also: The “Compile” target in Xcode allows an application to be ahead-of-time compiled to machine code, allowing the developer to avoid including the Ruby source in a shipping application.

No, it's an alternative implementation of Ruby 1.9 that allows you to interface directly with native OS X frameworks.

It's actually a bit more profound than that. macruby objects are Cocoa objects, so all of the funny edge cases that we used to have problems with in RubyCocoa have just gone away. For example, in RubyCocoa, if you try to serialise a proxy object representing a Cocoa object using YAML, and then read that object back in, the proxy is no longer created, and if you try to pass the object to a Cocoa API, the program crashes, because Cocoa was expecting a Cocoa object... The same operation in macruby works just fine (well, apart from the fact that YAML is evil, but at any rate, I have a macruby app that uses it, and it works fine)

Reply on news.ycombinator.com