[...] Twitter moving to the JVM more and more [...]

Excellent talk. Nice to see people starting to wake up and realize that the RubyVM will never be able to compete with the JVM. It isn’t that Ruby is bad, it is just that Sun/Oracle have spent millions tuning the performance of the JVM. As an aside note, for getting those performance stats out of the JVM, you may want to check out this tool: http://jmxtrans.googlecode.com/

Excellent talk. Nice to see people starting to wake up and realize that the RubyVM will never be able to compete with the JVM. It isn’t that Ruby is bad, it is just that Sun/Oracle have spent millions tuning the performance of the JVM. As an aside note, for getting those performance stats out of the JVM, you may want to check out this tool: http://jmxtrans.googlecode.com/

I do not understand. He put Ruby against JVM, but what about JRuby? JRuby is JVM language! It is also a lot faster than old Ruby 1.8 MRI. 

I think most people misunderstand the point made by Raffi…yes, JVM has awesome performance, but never try to solve performance issue at the beginning by sacrificing the agility offered by RoR. Not everyone is building Twitter, you don’t even know whether you will have performance issue. If you blame all the performance issue to the VM, you don’t know what you are talking about.

I don’t understand the comment that ‘Ruby can’t do scatter/gather’, or ‘Ruby can’t do event-driven programming.’

That’s what EventMachine is for – it’s a C++ Library with ruby bindings that does efficient IO through event-driven traffic. There’s event-driven database adapters that abstract away the mess of callbacks so you don’t even have to change your code – it’s just plug and play. I don’t know why these options weren’t mentioned, but I’m sure they were considered – so I’d be interested to hear why they didn’t make the cut.

JRuby is still a good deal slower. The problem is that Ruby source code doesn’t contain enough information to do a good optimization on. On the other hand, the new invokedynamic will speed up JRuby on the JDK, but it’s most likely still slower than Java.

I think people understand the point. It’s just like any other “Rails do not scale” issue, when you love and deeply invested to a stack, you almost always have a bias no matter what.

When people start a company, they don’t necessary pick the best tool. They pick what they know best. That’s point #1.

Point #2, if your Rails project require optimization (implement caching strategy, use async style programming, use queues, optimize your database, etc) far ahead before a hypothetically similar project written in Java or Scala, where is the productivity gain? Where is the pragmatic approach?

I fully agree with your last sentence: “Never ever try to solve a requirement that doesn’t even exist in your own app…” but judging from people/companies that use Ruby, they do have “performance” emerging as their requirement sooner than those who use Java/Scala.

The point is you probably never need that performance gain on the VM level (YAGNI) at all. Things are changing very fast in software development, your project could die or fail long before you really think about performance optimization. When you start a project and think that my project will fail because Rails doesn’t scale, you are doing it all wrong! What you really need is a tool that helps you iterate faster. Rails falls into this category. And that’s the productivity gain that I am thinking when starting a company.

As a pragmatic approach,  a half century of software engineering says that you should write the code first and worry about making it faster only if it is too slow. Donald Knuth is right: Premature optimization is the root of all evil. Don’t merely let the VM performance metric blind you to this fundamental truth. If you are chasing performance, Java/Scala is not your ultimate solution, C/C++ is, even assemble language .

I actually don’t see a problem when “performance” emerging as the requirement in the Ruby world sooner than others, say Java/Scala, because this “sooner” is very contextual. To give you more info, GitHub is on RoR since it starts, and till now they haven’t hit the so-called “Rails do not scale” point. So are many other projects. Besides, think about Twitter, they only recently try to port everything to the JVM,  after Rails has served them a couple years. All these facts tell you, this “sooner” may never happen to your own app.

[...] O’Reilly OSCON Java 2011 – Raffi Krikorian: Twitter: From Ruby on Rails to the JVM [...]

[...] infrastructure team gives a good overview of the move from Rails to JVM (Scala, Java and Clojure). http://ontwik.com/rails/oreilly-…Mohit Gupta • 6:26pmView 1 Comment Edit Link Text Show answer summary preview when [...]

[...] Study more [...]

[...] Read more [...]

[...] Read more [...]

[...] solving incredibly complicated problems.Twitter is an example of an incredibly complicated problem.http://ontwik.com/rails/oreilly-…But when you work on your own website, some basics are:Optimizing your images. Images take up the [...]

[...] Read more [...]

[...] [...]