War on Perfect

Posted by Nick Sieger Mon, 22 Nov 2010 18:30:00 GMT

I intended to give this brief as a lightning talk at RubyConf 2010, but unfortunately did not get a chance. Though I kept the message simple, I think if you sympathize with being a perfectionist you can find some part of these points that rings true. I know I still have a ways to go in heeding my own advice, and not only in software but in my life as a whole.

Thanks to Hiro Asari for the Japanese translations and Jeremy Hinegardner for the Rubygems.org numbers.

War on Perfect

I want to start a war.


A war on Perfection!




I hate this word.


I want to eliminate it from our vocabulary.


What is Perfect?


Ask 10 people, get 10 answers.


Different answers means disagreement.


Perfection cannot accept compromise.


Without compromise, we cannot get along, or get anything done.

妥協無しには、仲良くやって行ったり 何かを成し遂げる事は出来ないでしょう。

(Just look at politics in the USA.)


Perfect is lonely if you can’t agree or share with anyone else.

他人と合意や共有が出来ないので 完璧主義とは孤独でもあります。

We are human. No one wants to be alone.


Perfect is contagious


If you’re not embarrassed when you ship your first version you waited too long.


-- Matt Mullenweg マット・マレンウェグ

How many Ruby gems have never seen 1.0?


Any guesses?


17864 Rubygems 86837 versions バージョン

13496 gems without a version that does not start with “0”. 75 Percent!


I challenge you all to release 1.0 on your first push to Rubygems next time.


Perfect is impossible


If you seek it, you will never quite attain it.


You will worry it’s not perfect enough, and it will escape your grasp.


Perfect keeps you too focused on one thing.


Your mind will cripple you.


You won’t be able to finish it.


You’ll feel helpless because nothing is ever good enough.


Perfect ruins your productivity.


You’ll feel like your work is never done.


Perfect is harmful to your health.


We work too hard to achieve perfection.


We set our personal standards too high.


And rarely reach them.


So we worry about not being good enough.


This makes us ANXIOUS.


Anxiety can give you stress,


make you sick,


or even kill you.


We can’t be happy if we’re anxious or unhealthy.


We can’t be happy if we accept no compromises.


We can’t be happy if we’re alone.


We can’t be happy if we strive for perfection.


Matz knows this. He is WISE!


Ruby is not perfect.


(Matz knows this too!)


Matz made Ruby so we could be happy.


Perfection keeps us from:


making compromises,


getting things done,


enjoying each other’s company,


being happy.


And that’s why I hate it.


So you can either try to be:


Perfect [and be]








or you can be HAPPY.


I’ll choose to be happy. I hope you do too.



Tags , , , ,

New Orleans live music this weekend during RubyConf

Posted by Nick Sieger Thu, 11 Nov 2010 18:38:00 GMT

My boy Erik Jacobson from way back and also of Mama Digdown’s Brass Band is a New Orleans regular and knows the local scene well.

He graciously gave me the lowdown for this weekend. I’d like to make a few of these gigs; probably at least the Stooges at Hi Ho tonight, maybe Hot 8, Ellis and/or Cotton Mouth Kings tomorrow, and one of Shannon Powell or Wes Anderson on Saturday. Let me know if you’re interested by messaging me on Twitter.

Erik also mentioned that there might be a Second Line happening on Sunday afternoon that I might try to check out before I take off in the evening. Let me know too if you are up for that.

Ok, here’s Erik’s take:


Shamarr Allen @ Irvin Mayfields Jazz Playhouse. 8:00pm.

He’s a fantastic young trumpet player and a friend of mine. This is the nice/upscale club that is in the hotel on Bourbon Street.

Kermit Ruffins @ Vaughn’s. 8:00pm.

You probably know, but Kermit is a trumpet player and is a quintessential New Orleans character. Vaughn’s is a great local dive bar that is in the Bywater neighborhood out by the Navy Yard. You’ll want to take a cab there. There is also free beans and rice at his shows.

Stooges Brass Band @ Hi Ho Lounge probably around 10:00pm.

I got a hold of Walter from the Stooges and he said they were playing tonight. They are a fantastic brass band and it’s a great local spot to catch them. Good friends of Mama Digdown’s.

Soul Rebels Brass Band @ Le Bon Temps Roulee @ 11:00pm

This is always a good hangout. There will be a ton of people there. The Soul Rebels are awesome and always play pretty late into the night.

If you felt like being adventurous, you could hit either Vaughn’s or the Playhouse from like 9-10, then take a cab to the Hi Ho for a set until around 11:30 and then finish with the Rebels. That is a lot of music, it’s just so hard to pick which ones to leave out.


Hot 8 Brass Band @ 12Bar. 7:00pm

HOT, HOT brass band. They are good friends who have been up north many times. This is a new club that is pretty close you your hotel.

Hot Club of New Orleans @ DBA. 6:00pm

This is a great Django style band. I went to college with the violin player Matt Rhoady. He also hails from Mpls and went to Henry High/ This club is over on Frenchman Street near Snug Harbor.

Kid Chocolate Brown @ Irvin Mayfields Jazz Playhouse. 8:00pm

Cool young trumpet player and singer. He also plays in Los Hombres Calientes from time to time.

Ellis Marsalis Quartet @ Snug Harbor 8:00pm

This is certainly worth going to and I am sure he’ll have a good band with him.

New Orleans Cotton Mouth Kings @ Spotted Cat. 10:00pm

This place is really close to Snug Harbor and would be fun to hit after Ellis. Great traditional band with young cats. Good people watching too. This is a cool scene here I think it’s free too!


Soul Rebels @ DBA. 11:00pm

If you missed them on tonight, you can catch them here. This would be a good place to hear them.

Shannon Powell @ Irving Mayfields Jazz Playhouse. 8:00pm

He is so badass. You should really try to swing by if you can. He is the drummer that was on that Orchestra Hall gig I played this summer. Cool dude too. At 11:00pm there is also a brass band playing this club called the KinFolk Brass Band.

Wessell Andersen @ Snug Harbor. 8:00pm

I am sure you know him from Wynton records. He is amazing. It is a hard decision between him and Shannon Powell.

Tags ,  | 2 comments

RubyConf India 2010!

Posted by Nick Sieger Fri, 12 Mar 2010 23:21:04 GMT

I’m honored to be heading to the first ever RubyConf India in Bangalore next week. I’ll be delivering an update on Rails 3, JRuby, and what’s in store for the future of the combined platform in 2010. I’m looking forward to meeting you there!

I'm speaking at RubyConf India 2010

Tags , ,  | 2 comments

RubyConf: Parting Thoughts

Posted by Nick Sieger Mon, 05 Nov 2007 17:57:34 GMT

RubyConf once again was thoroughly enjoyable. I highly recommend it to any Rubyist who is on the fence about attending to make it a priority to go next year. Here are some quick, random notes that didn’t quite fit into a full post.

  • For those of you who stopped by expecting to see the blow-by-blow of every minute of the conference like last year, my apologies. I think I set the bar a little too high for myself. It takes a lot of energy to stay focused on the sessions for the whole day. Perhaps it’s appropriate to pass the baton on to James Avery or Eric Mill for their 2007 coverage.
  • Venue (Omni Hotel Charlotte): Generally speaking, thumbs up. There were a couple of annoyances, though. 1. No non-emergency staircase to get to your room, causing huge lines for the elevators at the end of the afternoon. 2. Coffee was removed from the scene before 10 am, raising speculation that it was a conspiracy to drive business to the Starbucks in the mall below. 3. Toasters blew out the sound system on Sunday morning, forcing a PA system to be brought out and throwing a wrench in the rhythm of the morning talks.
  • I have to give props to Dr. Nic for avoiding getting burnt by the toaster incident and handling it really well. To boot, he gave one of the most entertaining talks at the conference, as the RubiGen video is sure to become an instant conference classic much like Adam Keys’ one-man-one-act event from last year.
  • Werewolf: I played one game, miserably. I was a werewolf, and when cornered by another in the game, mustered up the quote “I’m not an aggressive player, I prefer to feed off of other people.” Wow, what a freudian slip. While I can sympathize with Charlie’s comments about the game (and I do really enjoy late-night hackfests), I also have to agree with Chad and the other commenters that the two are not mutually exclusive, and the Werewolf games are wonderfully inclusive of RubyConf newbies and veterans alike.
  • The two-track approach in the afternoon this year seemed to go well, despite making it impossible to see all the talks. I would have liked to have seen Erik Hatcher’s Solr talk, but instead decided to give moral support to Kyle Maxwell’s JRuby in the Wild talk. I also missed the Saturday afternoon tracks to hang out in Stu’s Refactotum session.
  • Lots of good quotables: check out Nihilist and Twitter for some of the back-channel chatter.

See you next year!

Tags ,  | no comments

RubyConf Day 3: Behaviour-Driven Development with RSpec

Posted by Nick Sieger Sun, 04 Nov 2007 16:26:00 GMT

David Chelimsky and Dave Astels: RSpec

describe TestDriverDevelopment do
  it "is an incremental process"
  it "drives the implementation" 
  it "results in an exhaustive test suite"
  # but also...
  it "should focus on design"
  it "should focus on documentation"
  it "should focus on behaviour"

class BehaviourDrivenDevelopment < TestDrivenDevelopment
  include FocusOnDesign
  include FocusOnDocumentation
  include FocusOnBehavior

When doing test-driven development:

  • Write your intent first. The smallest test you can that fails.
  • Next, write the implementation. The simplest thing that could possibly work.
  • Even though you may be tempted to think about additional edge cases, multiple requirements, etc., you should try to be disciplined and focus only on the immediate tests. Only after you’ve made one test fail, then pass, can you continue on to other tests.

RSpec history

Initially BDD was just a discussion among Aslak Hellesoy and Dan North in the ThoughtWorks London office. Dave Astels joined the conversation with a blog post stating that he thought these ideas could be easily implemented in Smalltalk or Ruby. Steven Baker jumped in with an initial implementation, and released RSpec 0.1. Later in 2006, maintenance was handed over to David Chelimsky. RSpec has evolved through a dog-fooding phase up to the present 1.0 product.

BDD is no longer just about “should instead of assert”, it’s evolving into a process. Emphasizing central concepts from extreme programming and domain-driven design, it’s moving toward focusing on customer stories and acceptance testing. It’s outside-in, starting at high levels of detail, rather than low-level like RSpec or Test::Unit.

Story Runner

Story Runner is a new feature intended for RSpec 1.1. Each story is supposed to capture a customer requirement in the following general template:

As a (role) ... I want to (some function) ... so that (some business value).

It uses a “Scenario ... Given ... When ... Then ...” format to express the high level stories. Scenarios are a series of given items, steps, and behaviour validations. Once the basic steps are established, they can be re-used. David even demonstrated a preview of an in-browser story runner that would allow the customer to play with the implementation and create new scenarios.


Pending is a nice way to mark specs as “in-progress”. You can either omit a block for your spec, or use pending inside the block to leave a placeholder to come back to.

describe Pending do
  it "doesn't need a block to be pending"
  it "could also be specified inside the block" do
    this.should_not be_a_failure
  it "could also use a block with pending, and you will be notified when it starts to succeed" do
    pending("TODO") do
      this.should_not be_a_failure

Behaviour-Driven Development in Ruby with RSpec is a new book David and Aslak are working on, due out early next year.

Update: David has posted his slides.

Tags , ,  | no comments

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.

Tags ,  | 3 comments

RubyConf Day 1: Morning Sessions

Posted by Nick Sieger Fri, 02 Nov 2007 15:35:00 GMT

Marcel Molina: What Makes Code Beautiful?

What is beauty? Marcel explores this topic, starting with posing the question to the audience. “My wife!” Marcel: Why is she beautiful? “Longer answer than you want!”

Marcel comes from a literature/linguistic background, and is interested in how meaning is conveyed, but even beyond the basic words themselves, but the context and expressivity as well.

Note: Marcel has given this talk before.

History of beauty

Pythagoras: was out in the street, heard the blacksmith’s clanging hammer, and was drawn to the noise. He recognized, through closer inspection, that the different sounds that came from the different hammers had relationships, and eventually saw similar relationships in other parts of nature, architecture, and so on.

Thomas Aquinas: Three things that define beauty: 1. Proportion. The economy of size and ratio of parts. The smallest thing that works. 2. Integrity. Well-suited for the purpose. 3. Clarity. Clear and simple.

Each of the qualities are necessary, but none are sufficent. For example proportion (economy) will often clash with clarity. This is especially true in code.

Applied to software

Case study: coercion. Converting XML strings into rich Ruby equivalents. Marcel’s initial solution was a CoercibleString < String, which used a generator to iteratively try to coerce XML attributes to a number of types, and return the results. ~20 lines of code to convert to 4 types. His second version was a simple class method on String with a case statement.

Kent Beck, in his book Smalltalk: Best Practice Patterns, writes a book about writing good software, but in Marcel’s opinion, arrives at a definition of beauty by describing aspects of code that reflect proportion, integrity, and clarity.

Niels Bohr: “An expert is a person who has made all the mistakes that can be made in a very narrow field.” Marcel calls his CoercibleString a mistake, but one that helped him learn more about coding.

Luckily for us, Ruby is optimized for beauty.

Jim Weirich: Advanced Ruby Class Design

Emphasizing “Ruby” more so than “Advanced”, through three examples that illustrate techniques not commonly found in statically-typed OO languages (Java/C++/Eiffel).



FileList sports globbing, a specialized to_s, and lazy evaluation. First version: class FileList < Array; end. Good idea, right? Well, with lazy evaluation, resolution of filenames happens only when the list is accessed, not created, so a lot of methods need to be overloaded:

def [](index)
  resolve unless @resolved

The problem becomes that FileList too closely mimics Array, and cannot distinguish itself in the case that matters. So it was changed to delegate to array rather than inherit.

Moral: when you want to mimic built-in classes, it might be better to implement #to_ary or #to_str rather than inherit.


What’s the problem here?

  b = Builder::XmlMarkup.new
  b.student do
    b.name "Jim"
    b.phone_number "555-1234"
    b.class "Intro to Ruby"

class is already a method on Object. This begat BlankSlate, which removes unnecessary methods from Object. Several techniques were applied to eventually arrive at the latest version:

  • Use undef_method to hide methods that we don’t want. Except, leave methods beginning with double-underscore alone (__id__ and __send__).
  • Catch new methods added via a method_added hook on Kernel, and an append_features hook on Object, to deal with methods defined and modules included after BlankSlate was created


Problem: magic conversion of Rails conditions to SQL. An example: User.find(:all).select{|u| u.name == "jim"}. We don’t really want to load the entire database to do this, but we don’t like writing SQL either.

Solution: Record the actions in the select block by yielding a special TableNode object that captures the method calls and translates to SQL on the fly. Now we can write User.select {|u| u.name == "Jim"} and have it still execute SQL

  • Capture methods called and wrap in a MethodNode to convert to SQL column references
  • Capture operators and wrap in a BinaryOpNode to handle ==, <, etc.

Clever! Will this work? Here are some issues:

  • Small issue -- ordering: User.select {|u| "Jim" == u.name} will not work without messing with String#==.
  • Bigger issues: && and || are not override-able in Ruby. What’s worse, ! has pre-defined semantics (in the parser) and cannot be captured.

Lessons learned

  • Don’t be afraid to think beyond prior experiences to come up with new ways of solving problems in code.

Tags ,  | no comments

Rubyconf Wrap-Up

Posted by Nick Sieger Tue, 24 Oct 2006 22:51:55 GMT

Whew! Back home from my first RubyConf, it’s taken me a couple days to collect some parting thoughts. As you might have noticed, I was pretty busy last weekend.

First of all, what an awesome and welcoming community. It’s going to sound cliché, but there are so many intelligent and motivated people walking around that you can’t help but be inspired to roll up your sleeves and get your hands dirty.

There were definitely some high points for me. The beauty and power of the language, even after using it for almost two years, still amazes me. Pretty much every piece of code I saw, whether in a presentation or looking over someone’s shoulder, had a clear purpose and communicated its intent better than any general-purpose machine language I have seen. The simplicity of Evan’s new Ruby-in-ruby VM, the syntax integration tricks of John’s RubyCLR project, the forthcoming RubyOSA APIs, and Geoffrey’s graphics programs, are all great testaments to Ruby’s power.

There was an implementer’s summit on Friday night, which I attended (see also coverage here and here). There are now at least 8 active implementations of Ruby (Ruby, Yarv, JRuby, Cardinal, Rubinius, MetaRuby, Ruby.NET, IronRuby), and two interop bridges (RubyCLR and RubyCocoa)! The biggest news was that there are plans to revive the Ruby testing project (formerly the Rubicon) and share as many tests as possible among the implementations.

RejectConf was a huge success, due largely to the indefatigable Adam Keys. Kevin Tew has a decent wrap-up of the talks that occurred. Charlie’s demo of NetBeans in-place refactoring feature drew a couple oohs and ahs and even one f-bomb. Heckle, in time, should be an awesome tool as well. Big thanks to zenspider for coordinating it. It’s destined to become an annual tradition. Perhaps the organizers of future RubyConfs could account for it in the budget?

On a lighter note, there were quite a few humorous moments that kept popping up. A summary may read like a list of inside jokes, so here’s some context. THAT GUY is a reference to a disclaimer in Zed’s talk about the know-it-all guy who always pipes up during your talk with skepticism. THAT GUY kept getting called out during the rest of the conference. Ani, the developer evangelist from Microsoft was pretty thick-skinned. She was heckled constantly about MS, Vista, and everything else, and still kept a smile on her face. And of course you already watched Adam’s one-act play, right?

My note-taking streak wasn’t quite perfect; I didn’t take notes Kevin’s mkmf talk nor Rich’s talk about indi, and I slept in and missed Justin’s Streamlined talk. Also, the beer was flowing for RejectConf, and despite the quality summer of code talks, I was spent. Fortunately, you can fill in the blanks by following along with Curt Hibbs and the rest of the blogosphere. Thanks for tuning in, and I hope you got something worthwhile here. See you next year!

Tags ,  | 2 comments | no trackbacks

RubyConf: Your Ruby in My CLR

Posted by Nick Sieger Mon, 23 Oct 2006 14:16:00 GMT

John Lam wanted to build a photo-flash-card application using Avalon and Indigo and Flickr, but also using Ruby as the implementation language. So along the way he decided to build an interop layer (a bridge) between Ruby and the CLR to do it.

Now that John has joined Microsoft, his new mission (bigger picture) is to further dynamic language implementations on the CLR.

Bridging type systems

  • Dynamic methods in the CLR allow you to do better than simply invoking the reflection API.

    Ruby          |  C               |  CLR
    shadow class  |  dynamic method  |  instance
  • Polymorphic inline caching -- caching method dispatches on different call sites based on the assumption that types don’t change that often

  • Generate shadow classes and method stubs using const_missing and method_missing
  • Overload resolution happens in the method shims (a one time cost) to choose, e.g., which constructor to use for System::Collections::ArrayList.new
  • Integration is done to make the CLR feel more Rubyish


  • This changes identity (proxied object):

  • This is less Rubyish, but identity is preserved:


There are trade-offs and warts to a bridge approach to Ruby integration on top of a platform such as the CLR: there is a need to inject artificial type information occasionally to be able to construct CLR objects (e.g., arrays -- Array.of(Int32).new(3)). Generics are evil! Simple stuff doesn’t seem so bad: List.of(Int32).new, but there’s more pain to be had (see John for details). John also built a RubyInline-like implementation for the CLR languages too, to allow for getting things done (even if it’s dirty). Finally, method overloading is a problem, especially when there is no equivalent Ruby type -- this gave way to instance_shim which is a sort of aliasing method that mixes in type metadata for use by the interop layer.

On the other hand, there are many places where Ruby (even in bridged mode) can make the experience of developing on the CLR better. Implementing CLR interfaces is a feature that allows Ruby objects to cross to the CLR side, (e.g., adding IEnumerable to Ruby Array). Performance across the CLR boundary (marshalling data) is ~100 times slower than C#, but still fast (3 million calls/second). Huge benefits are gained from using DSLs in Ruby to help with the implementation of the interop layer. Also, RubyCLR allows mixing in methods into CLR types, so we can re-skin APIs that feel clunky in Ruby. This is really leveraging the power of Ruby in the best possible way.

My take is that it looks like the RubyCLR project will probably not be seeing much further development, unless John finds a willing maintainer -- but this is speculation, I haven’t confirmed with John. Yet, the problem of impedance matching between type systems is a recurring theme in the dynamic language arena, and so John’s work is valuable in helping us to understand this issue.

More Info

Posted in  | Tags ,  | 3 comments | no trackbacks

RubyConf: YARV on Rails

Posted by Nick Sieger Mon, 23 Oct 2006 14:15:00 GMT


Update: corrected performance numbers -- 20x, not 20%!

  • Got a job developing YARV at the University of Tokyo! He’s now employed at Akhihabara, Otaku City.
  • Member of Nihon-Ruby-no-Kai
  • Present at RubyKaigi 2006 (200 tickets sold in 3 hours). RubyKaigi 2007 will be June 9-10 (Saturday and Sunday).
  • Member of Nihon-Perl-no-Kai
  • Co-author of Perl book on Parrot in Japanese


  • [Demo creating Rails app]
  • Create app with YARV (rails foobar)
  • Edit config/boot.rb, add a GC.disable line (there’s a bug to be fixed when he gets back to Japan).
  • Start up WEBrick, and it works!


  • Rite: code name of Ruby 2.0 (a.k.a. vaporware!)
  • YARV: Yet Another Ruby VM


  • Supported by funds from IPA (now finished)
  • Simple stack machine, with VM instructions, a compiler and interpreter
  • Optimization techniques to improve performance
  • Open source

Optimizations include compile-time optimization, native threading, specialized instructions, instruction unification, inline method cache, and stack caching. YARV can build with configure/make, but doesn’t work with AC 2.6 (maybe you know why?). It passes most of the Ruby tests, but misses a few due to implementation differences.

[Koichi showed a demo controlling iTunes on Windows with Win32/OLE with YARV, and a native-threaded scenario in IRB.]

Myths of YARV: YARV is great! YARV will solve all problems! It makes Ruby programs go 50 times faster! It solves character issues! It finds your girlfriend!

Truths: YARV is for running Ruby programs, fast. It provides up to a 20x speed up for some algorithm benchmarks (Ackermann, Fib), but not for others [graphs shown]. You assemble and disassemble YARV instruction sequences, or serialize and de-serialize them. They are just Ruby literals, so they can be packed in YAML or some other human-readable format.

require 'yasm'
require 'yaml'

iseq = YASM.toplevel([:a, :b]) {|ib|

p iseq.to_a.to_yaml # => (gave a readable YAML view of the assembly)


  • Ruby thread is mapped 1:1 to a native thread
  • Supports POSIX and Win32
  • Many existing Ruby libraries are not synchronized at the C level, so many C libraries need synchronization added to them
  • Thread model 2: 1:1 mapping, with a Giant Lock (GL). Only the thread that has the lock can run. No need for sync, but no parallelism
  • Thread model 3: Ruby threads in parallel, but when thread-unsafe code is executing, GL needs to be obtained
  • Mutex class will become builtin
  • Thread.critical will vanish (not obsolete, but unsupported) [this was a controversial point for some -- the comment was that it’s a near impossibility to keep it with a native threading model though, the two are in compatible]

Matz: 1.9.1 in 2007 Christmas, but Ruby 1.9.1 is also to be merged with YARV, so Koichi hopes to complete the merge by spring or summer 2007. Thread model 2 will need to be used to begin with.


  • set_trace_func hook functions -- what to do here? [It was suggested by Charles Nutter to remove it, to which Matz replied that we could as long as we have a good replacement debugging API.]
  • Catch up with Ruby 1.9
  • JIT/AOT compiler (AOT compiler started but incomplete)
  • Koichi also has a side project: high-performance Ruby, with the goal of making it easy to write performant code.


More developers and testers are welcomed to the project!

Posted in  | Tags ,  | no comments | no trackbacks

Older posts: 1 2 3