Charles Nutter

Sure... Nice write-up.

From the Hacker News site I have been following the recent controversy and even participated in some discussions. :-) Your Honor, I plead guilty! :-)

I cannot blame them (Twitter) when they seek their goals for a better business with higher quality and performance. I even respect their creative skills. So I don't have a beef with them even when Ruby gets caught in the polemic.

Ruby to this day continues to be an open source project put together by a community that for better or for worse has most core developers being Japanese.

But since about 3 or 4 years ago, Ruby has had other developers seeking to implement compatible Ruby versions... That is, Ruby has outgrown itself and continues to do so. JRuby, MacRuby, Rubinius, IronRuby...

At the end of it, though, Ruby continues being relatively slow when compared to other kinds of languages. But first read the following article to see some reasons why is that:
http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html

Since Ruby's beginning, it was not out to reach C level performance. And JRuby for one improves upon some of the shortcomings of the main C implementation of Ruby quite well, not without its own shortcomings though. :-)

So, what do we have in the controversy? Twitter is a little sick of complaints of it letting the ball fall when much more is required of their services, so they go overboard when defining a solid platform for it with Scala. Not to mention that they simply can't go…

I can comment on the JRuby results.

For the base perf numbers, I'm not surprised. We've known that we're roughly on par with 1.9.2 for some time, and many of the benchmarks in question have started to reach a point of irreducible complexity (e.g. you can only slice and dice strings so fast). It's good to see JRuby remains at or near the front of the pack as far as performance, especially considering we've made no major performance-related changes in almost two years.

The Linux versus Windows numbers are a bit surprising to me. If I were to make a guess, I'd guess that the JVMs used were not identical (perhaps like Isaac Gouy mentions, one platform was 64-bit and the other wasn't) or some other detail altered the performance characteristics of the test. But the performance drop does seem to be in line with other implementations, so perhaps Windows really does suck and there's not much we can do about it.

On the memory issue, I have a few recommendations.

JRuby by default allows the JVM to use up to a 512MB heap (the default is usually 32-64MB, which is rarely enough for most nontrivial apps). The JVM likes to use as much memory as you're willing to give it, to keep GC times low (nearly free) and to give it lots of room to breathe. Almost all these benchmarks could run in far less memory (maybe 1/5 as much or lower) if the JVM were choked down to that level. So it's not surprising to me that the memory sizes for these very object and CPU-intensive benchmarks start to…

There are a few reasons one might choose to use JRuby.

The most frequently cited reason is to take advantage of JRuby's generally quite excellent Java interoperability. In many cases it may be the best way to introduce Ruby into an organization with a large, legacy Java codebase. Further, despite its oft-maligned reputation, Java still offers the largest number of high-quality, performant FOSS libraries of any platform. In our case, we are developing a Rails application along with a supporting Scala library simultaneously. In my experience, JRuby/Java/Scala integration is largely painless.

Further, JRuby could legitimately be considered the best Ruby implementation. It's very rare to find pure Ruby code that works on any other Ruby implementation but not JRuby. JRuby is, in general, faster than Ruby 1.9 (and in almost all cases much faster than 1.8). Further, upcoming enhancements in JDK 7 may allow some very impressive speed-ups (see http://blog.headius.com/2011/08/jruby-and-java-7-what-to-expect.html).

This linked article:

http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html

is really outstanding. It shows you exactly why a language like Ruby is inherently slower than a language like Java. Mainly, because Ruby does a lot more work to give you the cool, dynamic capabilities that make people like Ruby in the first place. Of course, much of the cool work on speeding up dynamic languages like Javascript and Ruby is all about analyzing code to find places where you can safely make assumptions about the code (+ is not overridden here, so I can use the built in integer addition operator, etc.).

(I probably oversimplified that, but I hope it captures the general idea.)

The "Duby" language at the end makes me think of Common Lisp and how you can optionally declare types the compiler can use to compile faster code. Would it be worthwhile to add optional typing to Ruby?

(1) Syntax wise Ruby is a lot easier and more expressive than Scala. IMHO I feel that Ruby is an OO language with some functional sprinkles while Scala is a functional language with OO sprinkles.

(2) Ruby has a great ecosystem if you are building web apps. It's also got a lot of testing libraries. :) But in seriousness the number of libraries in non web/tooling space is slowly increasing as faster Ruby implementations have become a focus point. Also JRuby allows you use the vast ecosystem of Java from within JRuby.

(3) Performance wise I'm pretty sure Scala will outperform Ruby. I don't think JRuby will be able to compete either. Charles Nutter, JRuby Core developer wrote this blog post which explains why Ruby is hard to optimize ― http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby.html

Of course take everything I've said with a bag of salt! :)

The point my original post makes is that .NET having concurrent GC is not exactly groundbreaking. This doesn't have anything to do with the so-called expressiveness of C# relative to Ruby.

>The bytecode language is not standardized, and there is no standard assembler language for it

There is a formal spec here:
http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf

> New features to the JVM are only added when they are required for Java.

This is another false assumption:
http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

>I say it does rival [the expressiveness of] ruby, you say it doesn't, good discussion.

Not really, is more like a generally accepted fact. e.g. Ruby typically uses 2-3x less code than C# to do the same thing:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=yarv