IronRuby @ RubyConf 2009 – Part 1: Summary
Summary | What sets IronRuby apart? | Sneaking Ruby to the top / Embedding IronRuby | Project status
Now that the turkey has settled and I’m back in Seattle, I’m finally getting around to writing about my time at RubyConf 2009 in Burlingame, CA (not San Francisco, liars! ;)). I spoke about IronRuby, got to meet a bunch of the other implementers, and overall had a great time. Jim Deville also got to come along for free, since Microsoft was a Silver sponsoring of RubyConf – next year we should sponsor the internet-connections since everyone using Chad’s room’s wireless was, well, fun … but no promises ;)
My talk was all about how IronRuby is extending the reach of Ruby. The two areas I focused on was “running in the browser” and “scripting existing applications.” And all that was sandwiched with a overview of the project and a status update. All content from the talk can be found in my RubyConf 2009 GitHub repo, but I’ll walk you through the talk with a couple of posts:
- What sets IronRuby apart? (brief highlight of Silverlight support)
- Sneaking Ruby to the top
- Project status
Everyone else’s talks
Here’s my strategy for attending talks: open laptop and code until the speaker catches my attention. When bored, go back to coding, and repeat. I got nothing done at RubyConf; irritating and refreshing at the same time. Maybe it was the shotty wireless, but I’ll stick with saying the talks were awesome. Here’s what I liked:
Keynote - Yukihiro Matsumoto
Matz outlined a new language called ZEPT: A general-purpose dynamic language which is great for distributed programming and metaprogramming. After explaining this very familiar language in some detail, he then turned it around and essentially said, “Wait, it’s Ruby! Kinda.”
While Ruby’s syntax is great for metaprogramming and DSLs, it needs work for distributed programming to be really great, but this is being worked on. Ruby currently has most of the building blocks for distributed programming, like lambdas, enumerators, and continuations, and things like a lazy-array are planned for future versions of Ruby. He closed with, “You can create the future of programming by working on Ruby,” and that there are more advances in internal DSLs in Ruby’s future.
Code of Art (Jeff Casimir)
Jeff handed out actual paper for his talk, so he gets props for that. He demoed ruby-processing, a port of the Java Processing library for making fancy graphics and visualizations; it uses JRuby. The main demo was a very simple “click-and-make-a-random-sized-circle” … so simple I had to rip it off for my talk. So, I sent Jim off with my demo to hack it up, and now we’re close to having a full 2D-only-port of ruby-processing for IronRuby. More about that later though.
FFI – creating cross engine gems (Jeremy Hinegardner)
FFI, Foreign Function Interface, is a DSL for describing C-libraries in Ruby; very similar to writing a header file. A benefit of using writing an C-extension based on FFI is that it should be compatible with many ruby engines, as the compatibility burden is placed on the ruby engine rather than the extension implementer. Supporting FFI will be a reality for IronRuby after 1.0; I’ll put this on the project’s TODO list. Anyone interested in starting an FFI implementation for IronRuby?
MacRuby: Ruby for your Mac (Laurent Sansonetti) – slides?
Rubinius in One Act OR Rubinius: A War on Two Fronts (Evan Phoenix) – slides
Rippin’ off Python (Chris Wanstrath)
I actually didn’t get to see this since it was at the same time as my talk. I saw someone say on Twitter that this was one of the best attended talk at RubyConf. Jerk :)
Charlie talked about Duby and Surinx, his Ruby-derivatives. Duby is a statically typed Ruby-like language, while Surinx is a dynamic-typed language which depends on invokedynamic. Duby’s nice in that it’s not very JVM-specific (other than the backend), so an upcoming project of mine will be to write a CLR backend for this – having a Ruby-like language that is basically a facade on the CLR will fill in a lot of the holes we have with IronRuby, and hopefully influence some future IronRuby work – just like JRuby is planning.
No implementers care about Ruby 1.8.6 anymore; Ruby 1.9 is the focus for all future work. MacRuby isn’t even supporting 1.8.6. So why should IronRuby support it? Granted, JRuby supports 1.8.6, as well as other 1.9 features, but they have been a “real” implementation for a while. When IronRuby actually starts to get production apps, do we really think Rails 3.0 (which is Ruby 1.9 focused) won’t be standard by then? Personally I think IronRuby should re-evaluate it’s reasons for supporting Ruby 1.8.6; if we support 1.9, compatibility will get better as time goes on … where as supporting 1.8.6 is a sure-fire way to ensure a decrease level of compatibility in the future if we don’t keep up. Thoughts?
Also I got to meet Matt Aimonetti, of the “Pr0n Star” fiasco, but I’ll let that slide :) He’s seems genuinely excited about using Ruby in the browser with Silverlight, and also has always offered his help with promoting IronRuby on Rails; he interviewed me on the Rails blog not too long ago. I look forward to seeing greater collaboration between the rest of the Ruby community on IronRuby, and hopefully this is the start.