Back in May of last year, I went out on a limb and shared my best guess on how MacRuby could play an interesting part in the future of Cocoa and CocoaTouch. WWDC was just around the corner and the excitement about the platform fueled my speculation.
Then Apple dropped ARC right in our laps.
I was there in the dev tools keynote when they mentioned it. Everyone was shocked. Apple went all-in on reference counted memory management. Rather than switch to garbage collection, which they had already started to do in Snow Leopard, they announced compile time memory management. And they didn’t just announce it, they strongly recommended it. You had to be dense not to get the hint. This is the future of the platform.
It’s one of those crazy-bold decisions that has yet to fully play out (and is not without pain). Rather than switch to using a more modern language and runtime for official development, they are trying to update Objective-C and make it easier to use. On the one hand I was curious, but it also sent a chill in my spine.
That’s when I first started to realize that MacRuby was dead.
Well, not really dead. MacRuby was one of those kinds of projects that Apple supported openly in that “lets see what happens” kind of way. They’ve done this before with MacPorts, too. One of the problems they had with MacPorts was that package library maintenance is too much for a single vendor like Apple to handle. Package managers thrive when those who use the libraries chime in to help when their library needs to be updated. Apple is obviously not in the business of supporting third party libraries and the project languished as a result.
Homebrew took over and thrived in it’s place. Its fully decentralized nature built on the awesome community mechanisms at Github made it easy to jump in and contribute. Packages get fixed wicked quick even when Apple breaks things in each OS or Xcode release.1 And Apple has declared their support for the underlying toolchain to keep Homebrew working. It worked to move the responsibility away from the company and out in the open.
MacRuby is now reaching that stage. Matt Aimonetti just released an excellent synopsis of the situation over on the MacRuby mailing list.
It is time for us to stop looking to Apple to provide guidance, leadership and coding for the project, in other words, and take on those challenges for ourselves! MacRuby is already very powerful and comparatively stable as a development platform, now it’s time for us to take things to the next level.
This here is the rub. Can the community move it forward? Without Apple’s direct support, MacRuby will always have to play “catch up”. We can’t depend on it as an officially supported tool for app development. But that’s not the only way to use it.
The largest audience I’ve run into who wanted to see MacRuby on iOS are Rubyists who don’t want to write C code. Continuing to hope and use MacRuby in this way is foolish. But for those who have the technical know-how to support it themselves (like you would support a bundled version of Lua, Scheme, or another scripting language), go for it! This isn’t part of the magical Apple supported playground anymore, but there’s no reason it still can’t be expanded and used effectively.
Ruby is a fascinating language, warts and all. MacRuby is a great fork of it. The future is dependent on us. You want it? Go get it. They need our help.
Which is another problem, but one rant at a time, please.↩
My books...