RubyConf Day 2: Morning Sessions
Posted by Nick Sieger Sun, 04 Nov 2007 02:12:00 GMT
John Lam: IronRuby
Why IronRuby? John started with RubyCLR, which was a bridge between two languages/environments (.NET CLR and Ruby). Last year he didn’t know he’d be uprooting his family from Toronto and moving to Seattle. Now he finds himself in Microsoft trying to make sense of his new position. He describes a number of higher level goals for himself and IronRuby at Microsoft.
Change or die. Involvement in open source can only go up, right? The challenge is that the company is already doing well, so it’s hard to convince middle management that anything should change.
Open source. To their credit, the IronRuby team appears to be on the leading edge of open source at Microsoft (c.f Microsoft Public License). They also had planned all along to take external contributions, and have in fact started to receive them
Rails. One of the key goals is to be true to the language, and that includes being able to Run Rails.
Performance. Use IronRuby as a testbed for DLR performance testing.
John is showing the REPL now (running under Mono actually), pointing out that “integer math is now supported” (apparently early on someone pointed out that subtraction didn’t work) and that CLR list types automatically appear like Ruby arrays.
Heavy DLR pitch ahead. Performance history, how the CLR used to be slow for dynamic languages, and how it’s better now.
John is running the Rubinius specs now, and showing only 373 out of 1030 failing. (It looked like he was running the core specs only.) Praise for the Rubinius team!
It’s possible to bind C# types to Ruby using annotations. Lots of C# code being shown, including a mess of generated code.
John also showed a XAML/Silverlight demo that was scripted by Ruby.
Charles Nutter and Thomas Enebo: JRuby
JRuby: “Not Just” JRuby for the JVM. I found it hard to take notes for this talk since I’m so close to it. Fortunately, their slides were pretty verbose and comprehensive, and hopefully will be posted shortly.
Evan Phoenix: Rubinius
Rubinius talk in roller derby mode. Ask questions early and often.
What is the end game of Rubinius (or JRuby, or IronRuby)? Total. World. Domination. For Ruby!
Rubinius is 3 things: form, function, and elbow grease. Ruby::Syntax, Ruby::Behavior, and Google.search("crazy cs papers")
.
Rapid fire CS Nerd attack mode coming. Generational collection, bytecode execution, stackless, bytecode represenation, .rba archives.
Who would rather program C than Ruby? Java? C#? (Only one guy raised his hand that he’d rather code C.)
Hard-hitting portion of the talk. The kernel, broken down.
1.8
- 84,516 lines of C
- 0 lines of Ruby
1.9
- 128,786 lines of C
- 0 lines of Ruby
IronRuby
- 48,282 lines of C#
- 0 lines of Ruby
JRuby
- 114,507 lines of Java
- 0 lines of Ruby*
(*Even though I got heckled for saying it, JRuby does actually have some code written in Ruby that’s not the standard library.)
- Rubinius
- 25,398 lines of C
- 13,946 lines of Ruby
1.8 and 1.9 are really Ruby for C programmers. JRuby is Ruby for Java programmers. IronRuby is Ruby for C# programmers. But Rubinius is Ruby for Ruby programmers.
Dogfooding. Gives feedback, which enables tighter loops, improves the kernel, makes life better for everyone on the platform.
Road, rubber, all that jazz. Evan mentions that Rubinius runs 24 of 31 benchmarks faster than Ruby 1.8, but the numbers are shifting rapidly. Evan wanted a 1.0 for RubyConf, but he has come to realize that several things are more important than a milestone. Design, and the technical challenges, certainly. But more importantly, the community.
Taking a cue from the Perl 6 community, -Ofun
. The free-flowing commit bit, where patch sumbitters whose patches are accepted are immediately entitled commit rights, has given rise to 57 committers. 17 of these have changed more than 400 lines of code.
“#1.9
“
I’m guessing that should be 128,786 lines of C?
@Sutto: yes, thank you.
I think it’s important to point out that JRuby would include more code written in Ruby if it weren’t a severe performance penalty to do so. Rubinius runs nontrivial applications some orders of magnitude slower than other impls because of the addtional complexity introduced by many layers of Ruby code. I’m sure they’ll be able to solve their perf issues, and I believe we’ll be able to improve performance to the point where including some Ruby-based core class impls wouldn’t be such a severe hit, but it’s going to be very hard to beat implementations with thicker kernels in the performance game.