how hard would it be to do the same thing for Ruby... ? Much harder, but not impossible. The two issues are (a) how much of Ruby the language can be compiled t

how hard would it be to do the same thing for Ruby... ? Much harder, but not impossible. The two issues are (a) how much of Ruby the language can be compiled to C++ using Type Inference, and (b) For the stuff that can't be compiled, how often does it show up in production code? FB's PHP solution relies on having a large code base with few instances of code that doesn't compile cleanly. With Ruby, I suspect both issues are a problem. I think there's a lot more of Ruby the language that will be difficult to infer, and furthermore I think Ruby programmers tend to use those features a lot. That's just a guess, mind you. You could probably do a lot if you make some major breaks with tradition. For example, if instead of compiling Ruby source code you load Ruby classes, run all the meta-programming, then reverse-engineer the source (ParseTree can do this with Ruby 1.8 but not Ruby 1.9), you could basically do the meta-programming in interpreted mode but run the resulting code in compiled mode. I suspect that would work well for a lot of Rails programs where the hairiest stuff is run when classes are loaded, not on the fly when responses are being served.