Could Ruby be Apple’s language and API Future?
by Parveen Kaler
If you're new here, you should subscribe to my RSS feed. And you should follow me on Twitter here. Thanks for visiting!
There has been a shift in development landscape over at Apple. John Siracusa of Ars Technica recently published an article about Apple’s language and API future. I believe Apple is preparing to transition to Ruby as their next default language.
Today
Today, the Apple development stack sits on top of the GCC compiler. GCC compiles Objective-C, C++, and C code down into native machine code for devices that run Mac OS X and iOS. Core Foundation is a set of C libraries that provide low level operating system services and fundamental data types. On the Macintosh, Cocoa is the set of frameworks that sit on top of Core Foundation. Cocoa Touch is the set of frameworks that sits on top of Core Foundation on iOS devices.
Generally, developers build applications using the XCode IDE. XCode is the GUI layer that drives the compiler, debugger, and build system.
LLVM & LLDB
XCode also ships with LLVM. LLVM is an open source compiler infrastructure that is meant to eventually replace the GCC tool chain.
LLVM allows the system to compile and optimize code at compile-time, link-time, and run-time. The compilers from Microsoft have been able to do link-time code generation for a number of years now. This allows the system an extra phase in which it can both optimize code and provide other types of diagnostics.
The LLVM project originally started at the University of Illinois. Apple has a team of developers that work on the project full time.
XCode currently ships with GDB as the debugger. The LLDB project was recently announced with the goal to replace GDB as the debugger that sits on top of LLVM. Currently, Mac OS X is the only supported platform. Browsing the list of committers shows email addressees from Apple. The project also has a very Apple-esque description:
The goal of LLDB is to provide an amazing debugging experience that “just works”.
Complete transition to the LLVM/LLDB stack will finally put Apple on par with the .NET stack that Microsoft ships. This stack contains a language agnostic runtime with multiple code optimization points that runs native code.
The Dalvik virtual machine that ships with Android interprets byte code. A byte code interpreter has a few advantages over a stack that runs native code. Performance is not one of those advantages.
MacRuby & Rubinius
Where does Ruby fit into all of this? Both MacRuby and Rubinius use the LLVM compiler infrastructure to compile Ruby into native code. The MacRuby project is driven by Apple and it sits on top o Core Foundation and uses the Objective-C runtime to execute.
Apple has implemented Blocks and Grand Central Dispatch in their latest release of the Objective-C runtime. They are available on iPhone as of the iOS 4.0 update. This is one of the features that the runtime would be required to implement to support Ruby blocks and lambda functions. Objective-C is a dynamic language as is Ruby, however this was one of the missing features between the two languages.
The Transition
A number of features still need to be implemented for a full transition to the Ruby language. However, all of the fundamental building block for this transition are there.
A hat tip goes out to Boris Mann. We had a great jam session early last week that led to a lot of clarification of my thoughts.
Comments
No, it is more likely that they are using Ruby to learn from as far as language features go. That is why blocks and grand central came into being.
no way man, you’re nuts if you think apple will do this. Sorry!
The beautiful thing about MacRuby is its a ruby interpreter that runs on top of Objective-C so I think both Objective-C developers and high level ruby/python/perl developers all feel right at home. If you want to think in terms of the Mac development paradigm, you are welcome to. If you are new to the mac development world and prefer to ignore all of this, that is fine too. After all, `Array` is just an alias for `NSMutableArray` and `{}` is no different than instantiating a `NSMutableDictionary`. This is going to make adoption for both camps very painless.
I really really want this to be true. I love Ruby and I love the Cocoa frameworks, but I just can’t learn to like Objective C. The syntax is just so awkward and cumbersome. I hope that Apple is working on this. I would write so many more apps if I could use MacRuby.
I love writing Ruby and I’m thrilled by MacRuby project. But I don’t see Apple’s future in adopting MacRuby for mainstream consumption. Ruby is too exotic for huge body of old-school Mac developers living and breathing C, C++ and Obj-C. It would be really hard to re-wire their brains.
And the question is why would they do that? I don’t see any strong motivational argument in your article. MacRuby is just an experimental project. If it proves to be success, they will come with some C-like language. It may be next upgraded version of Obj-C or I can imagine javascript domination in the future.
I don’t follow your logic at all. If I understand you correctly, you’re saying that Apple uses Technology A and MacRuby uses Technology A, so Apple must be getting ready to switch to MacRuby?
That’s like saying I drink Starbucks and Steve Jobs drinks Starbucks so we must be buddies.
Right? Melvin R?
@Melvin
Apple sponsors the LLVM project and ships LLVM with XCode. Apple sponsors the MacRuby project and it has hit version 0.6. I postulate that MacRuby will ship with XCode in the future and become a first class citizen for writing Cocoa and Cocoa Touch Apps.
Sorry I wasn’t clearer in the post.
[...] full post on Hacker News If you enjoyed this article, please consider sharing it! Tagged with: Apple's [...]
Unlike many of the other commentators, this seem feasible enough, given another year or so and some progress in terms of performance and the API.
I think it’d be great to have the option to write Mac apps in Ruby instead of in Obj-C, and it seems rather Apple-like to be the first to having a language like Ruby be a primary/supported system language. Wouldn’t mind seeing a Lisp there instead, but Ruby a but of the way there, at least!
Well, hasn’t it been about 10 years since the move away from carbon? Maybe they work on a ~10-year cycle in their languages/frameworks?
Sounds too good to be true – however, lets face it, obj-c is quite ugly compared to the likes of java/c#/ruby these days.
One other thought – maybe they’re worried about the influx of developers to the android platform given that it has a much friendlier language (java) ?
As much as I like Ruby that would suck if Ruby became the default. I really prefer Objective-C when writing Mac apps it just feels better, lets face it Objective-C is awesome!
Ruby as the default language? No. What you’re describing is exactly what NeXT and Apple sort of tried to do with Java about a decade ago. They had written a bridge between Objective-C and the JVM and exposed the Cocoa APIs in Java, and you could write Cocoa apps in Java. All this was in place by the time 10.0 shipped. (I was tangentially involved in some of this, as I worked on Apple’s Java implementation at the time.)
The end result was that performance wasn’t good enough (some of the system apps like TextEdit and Calculator were originally written in Java and then converted back to Obj-C before 10.0 shipped because they took too damn long to launch.) Few developers ever bothered to code apps in Java. The bridge was abandoned.
There is currently a Python-to-ObjC bridge that’s been shipping as part of the OS for several years. You can build Cocoa apps in Python today with the stock developer tools and ship them. I think there are a couple of apps that do this, but not a lot.
Ruby has the same problems that Java did — performance and footprint — and moreover it’s not as popular as Java was in the late ’90s (remember that crushing wave of hype?) The LLVM implementation in MacRuby looks very promising, but I don’t think it’s going to make Ruby any faster than Java. Remember that Ruby 1.8 is one of the slowest mainstream scripting languages, so the tremendous improvement in MacRuby is measured relative to that; it’s still not a barn-burner in any absolute sense, definitely not compared to native code.
Finally, consider that currently most of Apple’s momentum and attention are on the iOS platform, not the Mac. iOS is not a promising environment for writing apps in Ruby, given its memory constraints and slower CPU speeds. So strategically, shifting to Ruby wouldn’t make much sense for Apple at this point.
This is something I’ve been considering for a while myself. I’m sure Apple are considering this route, they seem to be exploratory, but not afraid to dump unfruitful side projects.
I’m not Ruby could ever be memory efficient enough for iOS devices. But if anyone can get it there, it would be Apple.
Nope, Apple usually are betting on winning horses:)
Given the similarity between Smalltalk and Objective-C on the one hand, and the implementation of Smalltalk (via LanguageKit) on Top of the Objective-C runtime through one of the llvm core developers in LLVM/Etoilé on the other hand, I would suggest, that apple switches over to smalltalk (finally).
http://etoileos.com/
I’m not sure why but after reading this article I felt like you thought MacRuby would replace Objective-C. In another comment you clarified that you think it may become a “first-class citizen” so I feel a little more sane after reading your comment
As for the topic itself, “MacRuby becoming a first class citizen for Apple” – that would be truly awesome, and I love the work Laurent is doing on MacRuby but unfortunately, I think all you will ever get from Apple is “No Comment”.
A nice idea to speculate on, though
The article seems to be entirely conjecture based on the fact that Apple uses LLVM and so do a couple of Ruby implementations. No other evidence…
Unladen Swallow (a Python implementation) uses LLVM too as it goes, and Apple already use Python in various parts of their operating system / infrastructure. Apple even employ the leading Twisted developer.
The reason Apple uses LLVM has nothing to do with Ruby though (or Python for that matter).
[...] admin Рубрика Ruby, Программирование, Языки http://parveenkaler.com/2010/06/30/could-ruby-be-apples-language-and-api-future-3/ (or on Ruby Inside) There has been a shift in development landscape over at Apple. John Siracusa of [...]
I’ve used Ruby as my primary development language (w/Ruby on Rails) for a number of years, and as much as I love it I think its domain is too restricted to adequately play the role you’re trying to give it. I would much rather write Objective-C for native applications if only because using Ruby in an IDE is a painful process. I agree that, eventually, something will supplant Cocoa and Objective-C. My money is not on Ruby.
my wild a*s guess is you are WRONG. however it would be awesome on so many levels if you are
right! thanks for putting this out there!
“Apple has implemented Blocks and Grand Central Dispatch in their latest release of the Objective-C runtime…one of the features that the runtime would be required to implement to support Ruby blocks and lambda functions.”
I’m not a language designer but….
Blocks and lambdas are interesting and valuable language features in and of themselves. They allow for a more functional and ultimately more declarative style of coding, probably regardless of the language in which they are implemented. I imagine it was these notions, and not the idea that it would aid language developers, that were taken into account when the Block specification introduced.
Incidentally, the statement that blocks “would be required to implement to support Ruby blocks and lambda functions”, is just silly. MRI Ruby is implemented in C, no? Standard C has no notion of lambdas, blocks, or closures. The closest language construct would probably be a function pointer. That appears to be enough.
Just wanna point out that Dalvik has JIT since Android 2.2, it compiles into native code.
You guys forget that Apple has a Server platform, so MacRuby with Ruby on Rails would be a potent combination for Server development. Also with the MacRuby, the performance would be 1:1 with ObjC and a 1st class language along with ObjC.
It can be argued that MacRuby will allow you to more easily take advantage of blocks and GCD, with built in generational garbage collection without the verbosity of ObjC or the ambiguity the dot implementation of ObjC either for those that prefer dot notation.
MacRuby is an Apple sanctioned project, not some hobbyist project.
We don’t know their commitment to it, but it’s a closer connection than just “Apple uses LLVM and Ruby uses LLVM”, it’s more accurately “Apple is using LLVM to implement Ruby”, which is a much stronger statement.
[...] Could Ruby be Apple’s language and API future? (parveenkaler.com) Share and Enjoy: [...]
You can already write Mac apps using Ruby with MacRuby, that’s what it’s for! Give it a go, it’s a lot of fun. The team working on it are top chaps as well. I would love to see it become the standard but who knows if this will transpire. One thing I would like to see is a resolution to the garbage collection issues on iOS which are currently a barrier to writing iPhone/iPad with MacRuby. It would be beyond awesome to be able to develop apps for desktop mobile and web all in the same language.
Why would anyone use such a kludge of a language as Ruby? I’d rather they use Python or, possibly better yet, develop their own new language with all the power of Objective-C but with modern features and a cleaner syntax. It’d obviously have to tie easily and tightly with code written in C/C++/Obj-C.
The language in this post is misleading: “I believe Apple is preparing to transition to Ruby as their next default language.”
Apple aren’t making a “transition” to Ruby, but they are paving a way to better support it. It is, as you say in your comment, on track to become “a first-class citizen.” It will not be a replacement.
Onwards and upwards, though. I love Ruby (sorry, MikeFM).