Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

Stop Watching Sophie’s Choice (And Get Some Work Done)

I woke up this morning to Kirin Dave’s cantankerous rant about how Ruby’s going down the tubes. The whole post was a giant whine-fest, with the exception of the beginning, where he heaps faux past praise on Ruby to justify his complaints.

The entire post read kind of like Joe Lieberman supporting McCain: “I used to be a Democrat, but now I think Obama’s in love with terrorists.” Dave didn’t even really attempt to be even-handed in his critique (if I can even call it a critique); he just goes after the Ruby language, interpreter, and community with the full force of his giant… rhetoric.

Let’s take a look at Dave’s claims:

Claim 1. Ruby’s interpreter is so outdated, it’s impossible to write code without it leaking memory. As evidence, he points to a case encountered by Tom Preston-Warner in his God monitor library. What Dave fails to point out is that despite his claims that Ruby 1.9 is basically useless, the last post in the thread he references informs the readers that the bug is fixed in Ruby 1.9.

He also doesn’t inform the reader that many large web applications, including,, and, not exactly tiny web sites, are running on infrastructures that depend on this “outdated” interpreter. While I’m not going to claim that the Ruby interpreter is all rainbows, it’s hardly the problem that Dave claims it is.

Dave also dismisses JRuby with a wave of his hand, using the argument that it’s not useful for web applications because it can’t be used for scripting (which Ruby is frequently used for). This is a classic example of a red herring fallacy. The existing “terrible” Ruby interpreter works just fine for scripting, where the supposed memory leaks aren’t an issue. As a result, dismissing JRuby, which solves all of his other deployment concerns, is just pure malarky.

Claim 2. Ruby is the slowest thing imaginable. I’ve tackled this argument with some vigor before, but suffice it to say that real-life Ruby applications must be compared against real-life PHP or Django applications, and they perform quite well. Even Rails, not exactly the fastest Ruby web framework, beats out CodeIgniter in Hello World benchmarks, and is dead even with CodeIgniter on more robust benchmarks. Comparing it with CakePHP, which is a closer feature-for-feature comparison, Rails completely destroys Cake in all benchmarks.

Merb, which takes more effort to avoid being slow, does significantly better than Rails, and beats CodeIgniter on hello world benches by around 5x. The reason for this is that despite Dave’s claims that the Ruby community is stagnant, some of the worst speed offenders have been handled by native extensions that provide speedups for the community without the community having to drop into C all the time. The most recent example: ThirdBase, a library to make Ruby’s date facilities an order of magnitude faster than the built-in Date class.

Because the Ruby interpreter has a fairly good C API, developers without commit access have been able to improve the speed of everything from web servers (who uses the stdlib’s webrick!?) to XML parsing (why use REXML when you can use Nokogiri and gain orders of magnitude in speed). Real-life applications are simply not as slow as the benchmarks (which even Dave admits are not dispositive) would seem to imply. Real apps simply spend more time IO-waiting on things like databases or grabbing strings out of cache than in calculating the fibonacci sequence.

Claim 3. Rubinius didn’t happen and JRuby… these are not the droids you’re looking for… Rubinius didn’t happen. Somehow, in all his bloviating, Dave didn’t really address JRuby at all. Let’s take a look at his hand-wave real quick:

jRuby is great, but I kind of liked the illusion of a small memory footprint–a lot of Ruby use is in scripting and starting up a “java -server” instance is not really desirable for that. 

So let’s take a look: JRuby has too large a memory footprint. Actually, not so much. When you take into consideration that you only need a single JVM instead of multiple processes, JRuby starts looking very competitive. In fact, when you start factoring in the impact of real threads on IO-wait, JRuby starts killing MRI.

I already addressed the other claim: Ruby is used in scripting and JRuby is thus unsuitable for it. For those cases, MRI works just fine. Even if we were to grant Dave his claim of unbeatable memory problems, scripts can handle a slow 200k leak every 10,000 seconds (the big gotcha memory leak). As a result of all the effort around alternative implementations (and spearheaded by Rubinius), JRuby and MRI are remarkably compatible. Developing on MRI (for fast startup times) and deploying on JRuby (for a rock-solid memory footprint and great concurrency handling) is viable by design.

In essence “There are no good choices for a Ruby interpreter” is straight-up not true.

Claim 4. Ruby’s future is… yawn. Dave takes a look at the new features in Ruby, and based on the future of the Ruby language, decides that Ruby itself is booooring. He makes one tiny mistake when he claims that better FFI was only in alternative implementations: the aforementioned C API made it possible for wmeissner of the JRuby team to roll out a 100% compatible version of Rubinius’ FFI (which they have now adopted) for Ruby 1.8.

Probably the most misleading part of this claim is ignoring all the work being done on Ruby libraries. I can be competitive with Rails from time to time, but even I’m not going to claim that Rails is no longer producing good work. And Merb is fairly well acknowledged for innovation around these parts. Dave says:

And what do I have to look forward to in the Ruby world? Essentially the same promise that I heard in late 2005, “Christmas will bring a faster ruby.” 

This assumes that the only interesting things happening around a library are related to its core interpreter or the core language. While Ruby 1.9 does see some improvements to the complaints that he raised, and JRuby flat-our resolves them, Dave’s fundamental mistake is here. By assuming that the only way the community around a language can get better is by improving its core, he is ignoring reality: there are tons of exciting developments around Ruby that are being pushed by its users.

Dave closes by saying:

People will leave trying to stake out The Next Big Thing™, bleeding the Ruby talent pool dry and making it even less capable of recovering from these bad fortunes.

I predict the opposite. The Ruby talent pool will continue to grow, and we will continue to produce new, innovative, and exciting projects. JRuby will continue to improve and Rubinius will be released, sparking a new Ruby speed war that will lead to the faster Ruby that so dominates Dave’s dissatisfaction. And the Ruby community will continue to learn from other languages, like Python and Erlang. It’s only going to get better from here.

17 Responses to “Stop Watching Sophie’s Choice (And Get Some Work Done)”

It’s great to see a reply to this post from an active member of the Ruby community. I agree that it was one-sided and offered only a negative perspective on the subject.

I think there are great and interesting things on the horizon. The Ruby language is evolving and we have some great frameworks and tools that have been developed from it.

It will be interesting to see where we are in the next couple of years!

Plz to be linking to rant kthxbai.

Bandwagon jumpers: “Oh look! People are leaving! Why!? Well, nevermind, I’ll join them and bash on stuff I previously admired!”

Good writing.

Ruby, as a language, is one of the best ones out there (certainly the more fun).

KirinDave’s post just proves that we spend too much time in the Ruby community talking about problems instead of talking about HOW WE’RE GOING TO OR ACTUALLY ARE SOLVING PROBLEMS.

I prefer Zed’s examples of *actual* flaws in the Ruby interpreter, several (or all now) since patched, to KirinDave, et al bitching about Ruby without actually contributing to improving the interpreter. Hello, we ARE open source. Don’t like something? Fix it. They won’t accept your patch? Fork it. Too lazy to do either? Sit down, be grateful that you even have Ruby, and, as you said, “Stop watching Sophie’s Choice.”

Of course, just like you and Renae Bair, I’m ranting about ranters. And now for something completely different.

that dismissing hand wave you talk in point 1 is called “the singularity wave”. It’s a hand wave that has the ability to negates all reason, logic and historical data and creates automatically an isolated singularity. No further proof is required, just the hand wave.

Unfortunately it works only on people that believe in the singularity wave, usually the person waving.

Everybody else sees it as complete and utter bullshit.

Like most common diseases if you know them you avoid them and take measures to protect yourself from their carriers.

Great post! Thank you for this response :)

I have just one nitpick. You say that the compatibility effort was spearheaded by Rubinius. Rubinius did spearhead the RubySpec effort, that much is true. And RubySpec has provided a much better standard suite of tests than we had previously. But there’s some historical facts missing here. JRuby ran Rails in 2006 and we’ve had production users since 2007, before RubySpec ever really got going. During the past four years we’ve worked heavily on compatibility using 5-6 test suites that already existed, while continuing to build out our own suite in response to found bugs. And RubySpec is now the “7th” suite, since we still run the others. So it’s a bit misleading to claim Rubinius initiated efforts toward cross-impl compatibility, since JRuby was compatible enough to run production Rails a good year or more before RubySpec started.

Otherwise, great post, and thanks for your comments about JRuby. I know the Ruby world is going to see more and more great things from JRuby, and I hope more people will move beyond “J” bigotry and help us make JRuby even better.


Well said, Yehuda. Thanks for taking the time to write this.

Very well done. Always good to see someone calling BS when BS is clear.

“…but suffice it to say that real-life Ruby applications must be compared against real-life PHP or Django applications…”

What does this even mean? Django isn’t event a language! If you really meant Python, I would be careful comparing Ruby to Python or even Perl for that matter. Ruby is great for writing web applications but the 1.8 interpreter is much slower than Python or Perl. For me real-life applications include churning through very large text file. Last time I did this with Ruby on a 2 GB file, I rewrote the script in Python before the Ruby version was even finished! I let the Ruby version run for over an hour before shooting it dead. The Python version took less than 10 minutes.

Also, I could be interpreting KirinDave’s post wrong, but I saw it more as an outcry in regards to the Ruby development process. Don’t get me wrong, I love Ruby but before Ruby I worked in Java and Python. With those languages the growth was guided by the community and was visible. Java has JSR’s and Python has PEP’s. What does Ruby have?

Wow, a lot of hate here. I think you’re coming at it from the perspective of people with a mature application platform in a competitive environment, and one that we’ve all been involved with bitterly fighting for legitimacy on. Anyone, including you Yehuda, who says I’m heaping false praise on ruby is full of it, and you’re pulling a low blow. I’ve been in the ruby community for a long time and used it on a lot of projects, and worked for over a year on a new ruby-focused alternative for dynamic-cluster based ruby webapps.

And I’m a little mad that people keep saying, “He dismisses JRuby out of hand.” I don’t dismiss JRuby nearly as blindly as you think. The reality is that I can’t use it in my day to day ruby work (and I have a lot of it), because I’m working in heterogenous environments trying to use Ruby for one of this original (and brilliant) applications, as a glue layer. A *lot* of ruby code functions in this way (historical necessity). Are we going to dismiss that out of hand as well?

Yes, JRuby may be the light and the hope for the Rails and Merb communities, and I think that’s awesome and I hope it’s true. But it’s not going to help me and a lot of other people working on integration work. I’ve already got a prolog interpreter, a complex C runtime and a ruby interpreter all in one process for a specific project, now you expect me to shoehorn in the JRE? Oh wait, I suppose I’m “doing it wrong” trying to use Ruby.

And the thing is, before I published I went and talked to a lot of very respectable, competent rubyists and even game them early proofs. I got a lot of tweets from very prominent rubyists saying, “You’ve said what I’ve been worrying about for some time now.” I don’t want to bash ruby, I want to shoot up a flare and say, “Guys, if we keep on this path we’re going to be the next perl6, and I don’t think anyone wants that.”

@kirindave I certainly didn’t mean to be spewing hate. Nor did I mean to imply that you hated Ruby.

However, your general theses are fairly flawed. While JRuby might not have worked for your very specialized application, your argument was about the future of Ruby in general. In general, Ruby applications are not linking a C runtime, Prolog, and Ruby.

But if they were, you could use JNI or JRuby’s FFI and a Java Prolog interpreter (a few are at

Are your concerns about memory size and startup time or GC? My biggest complaint about your post was just that it seemed to be a muddled argument that ignore a number of good solutions and projects that are on the cutting edge of Ruby.

Rather than stagnating, Ruby’s growth and innovation are only accelerating. I was confused about your arguments to the contrary.

@wycats My goal wasn’t to point-by-point refute ruby, so I’m sure that my technical arguments aren’t laid out clearly enough to resist a point-by-point attack. I’m not really going to go to that level of detail in a comment either, so work with me a little bit here, please. :)

I don’t consider my application terribly specialized though. In my time since 2003 writing Ruby, I’ve been writing glue code between multiple libraries and interpreters as a matter of course. I did it for Lockheed (bindings to control software), (classifier gem, which I don’t maintain anymore), and You don’t see a lot this kind of code open sourced, but it’s out there and it’s real. Even the Merb project is working off a C binding. If the JRuby FFI can cope with your needs, that’s great. I quietly explored using it and found it insufficient earlier this year, and maybe I should revisit it.

(Aside, do you really want us to re-write a massive prolog app for the java prolog interpreter? Sir, I have to think you’re not serious about this or just a little uninformed about the lisp-like condition of prolog interpreters).

For JRuby, my concerns for my specific work (in order of priority) are:

1. The minimum startup size of a ruby interpreter in Java. Unless you’re willing to radically change your infrastructure to go threaded, it’s very expensive do do the traditional deployment and run many procs on one machine simultaneously. I could re-engineer, but it would sure be nice if I didn’t have to. And that’s the promise that other optimized ruby projects

2. The underlying engine is a massive, complex system with a huge soup of requirements. It’s a neat piece of software, but way overtasked for modern use. I think that it behooves Ruby to have its own interpreter, and I am not in the camp of people who think writing new, specialized VMs is a fool’s errand.

You say that Ruby’s growth and innovation are accelerating, but this is not the issue. Ruby’s *core* is stagnant. While other interpreted environments are skyrocketing towards nearly compiled-code performance with dynamic compilation and optimization, Ruby’s interpreter tech is stagnant and it’s difficult to make the case that there is a clear evolutionary path forward.

We’re at a fork in the Ruby Road. Many divergent, mutually exclusive paths stretch forward before us. Without a clear, dominant ruby implementation to migrate to the community fill fracture into numerous sub-ruby groups, each with code that they can’t quite share with the other group (could you write a deployment-quality version of merb that runs well on rubinious and jruby, right now?) I’ve seen this problem in the Lisp community and the consequences are… let’s say they’re not optimal.

It’s doubly frustrating because all around us there are amazing things being done with other interpreted languages. Working with Javascript lately has been incredibly rewarding. I want my Ruby skills to remain relevant!

@kirindave I’m not sure what you’re asking. Merb runs basically the same, unmodified, on all Rubies it runs on. There are a few cutting-edge features (like action-args) that require a different implementation on different implementations, but we’ve actually been working together (including the MRI folks) on developing an API that could be considered “official”. Here’s an 89-message post on ruby-core discussing it:

As someone who is actually worried about the potential fracture of the implementations (and who has had to deal with that in JS in my work on jQuery), I’m relatively pleased with the state of Ruby on that front.

The RubySpecs project has taken a very tenuous situation and created a crop of Ruby implementation that are almost completely compatible. It also provides a way to punish implementors that are building “forks” of Ruby, and so far no one has stepped up to receive that punishment (all known implementations are using RubySpecs as a measure of completeness).

I just don’t see the future of Ruby as one of “many divergent, mutually exclusive paths”. Where’s my mistake?

@wycats Alright, I’ll make a more formally constructed argument. The comments field of your blog is probably not the best place to do it, so I’ll write a post within the next few days. I think this discussion is valuable to have.

In the meantime, I don’t suppose you’d reconsider the initial part of your post where you call me a liar and and compare me to Joe Liberman supporting John McCain? Because you pretty much outright imply I’m lying about liking ruby to candy-coat an unpleasant point by association. This is a touchy subject, and I think it’ll all go better if we stay civil.


Perhaps there’s no point in arguing, but the analogy is valid :P

I would also very much enjoy seeing a more concrete discussion of why Ruby may or may not have FAIL. And global discussions of whether a language or technology is “good” itself is sort of a red herring. Ruby does have fail at some things, because like all technology, it’s got things it’s good at, and things it’s not good at.

Really a discussion about leaving a community, or whether a particular ecosystem meets your needs is always a subjective one. This is particularly why i find all these Ruby Shark-Jumping posts ridiculous.

Zed didn’t flame out of the community because of technology, he flamed out of the community because he either didn’t like people or didn’t want to deal with them. That’s a social problem, not a technology problem.

If the tech works for you that’s great. If it doesn’t, that’s not Ruby’s problem. That’s Ruby not fitting what you need it to. Or, even more likely, you losing interest in exploring ways to make Ruby fit into your workflow better, rather than some other technology. Then again, perhaps another technology would be a better (easier) fit. I don’t know, again, it’s subjective.

Leave a Reply