Comment by krohrbaugh | Hacker News Reader

Comment by krohrbaugh | Hacker News Reader

Parent Full thread

Engine Yard's objective is to drive Ruby adoption as a whole. Everything they are doing with open-source aligns with this.

Their current strategy seems to be based on three observations:

1. There are a lot of Windows users in the world and Ruby sucks on Windows.

2. There are a lot of existing companies using Java still and many are scared of Ruby.

3. Even if people get past 1 & 2 a lot of people are still scared off because "Ruby/Rails Doesn't Scale" (i.e., MRI is slow).

They are executing against all three of these barriers with their various initiatives:

1. Make Ruby a better platform on Windows: Rails Installer, SQL Server ActiveRecord adapter and including Windows as a target platform for their VMs.

2. JRuby as a gateway drug to the Land of Ruby; _could_ end up being VM winner too.

3. Rubinius as a possible MRI replacement, if they can make it technically superior and rally support within the community. (Think Merb -> Rails 3)

With this in mind, it makes perfect sense for them to support both JRuby and Rubinius.

It also makes sense for them to not be too overt about at least some of these goals. (See Merb vs Rails compared to SlimGems vs RubyGems.)

> JRuby as a gateway drug to the Land of Ruby; _could_ end up being VM winner too.

I don't get the "could". JRuby is among the fastest, gives you access to a massive amount of OSS and infrastructure, and fixes Ruby's threading.

It's done these for years at this point.

In my mind the question is more along the lines of "why should I use anything _but_ JRuby on a new project?".

It's blasphemy I'm sure, but I just don't see the point in C-Ruby for new development at this point. It's legacy. JRuby, as the last-man-standing among the major Ruby VM implementations now that IronRuby is dead and everything else is vapor (Maglev) or niche (MacRuby) is the default modern Ruby implementation to my mind.

So let's assume Rubinius is great, and the GIL is clearly a major step forward. Is EngineYard's intent really to supplant YARV with Rubinius?

Because that sounds great to me.

I've never seen EY say that though (they might have and I just missed it). If that's the vision, I'd rather see them come out and say it. Having developers guess, and having any ambiguity at all around the future of these projects and the messaging surrounding them doesn't inspire confidence.

It's blasphemy in that your use of JRuby is inconsequential to rubinius. Not everyone uses JRuby, and the non JRuby using world would like the GIL thread locking abilities in their interpreters without java+JRuby.

Native c/c++ ruby isn't legacy in everyone's environments, just perhaps yours. Why does EngineYard need to justify both implementations? I don't use JRuby at all outside of occasional curiosity. But I'm also not calling it useless in the same way you're basically attacking any non JRuby ruby implementation, which apparently includes MRI. Which is arguably the "default" implementation. Language implementations aren't a zero sum game. Work on one doesn't mean we can't have another. I don't see the Python people complaining about PyPy and vice-versa, they both serve their purposes.

Anyway off to bed.

Well put. JRuby and Rubinius both have rich futures ahead of them, and they're going to be largely separate.

If you want to use C extensions, Rubinius will be a better fit since it matches the MRI process model better. Rubinius will also map more directly to underlying OS APIs and quirks than JRuby, since we have to either use the JVM's vanillified versions of APIs or do the hard work of routing around the JVM with our own native libraries. And if you're a Rubyist looking to hack on internals, Rubinius is certainly more approachable right now. We hope to implement more of JRuby in Ruby in the future, but we'd need a really good reason to throw out fast, working code to make a move right now.

If you want to run an entire Rails site in a single process, JRuby's going to be the best option for a long time. C extensions required for native Ruby impls to interface with databases, etc, will always force trade-offs in memory management, concurrency, and process models. Those trade-offs do not exist when running on JRuby and using Java equivalents of those libraries. As a rule of thumb, the more unmanaged code you have in your application, the more hassles you're going to have. Native impls do almost all their interaction with the outside world via unmanaged code (C exts for DB access or fast memcaching, C-accelerated servers like Thin or Unicorn, etc). That's a problem.

If you just want to run some Ruby code, both implementations are going to serve you well. You're going to need to evaluate all options before deciding, and both implementations are going to be excellent Ruby implementations first and differentially interesting platforms second. And therefore, as you say, it's not a zero sum game. We'll all bring different features and weaknesses to the table, and users will choose which impl fits their needs best.

    JRuby is among the fastest, gives you access to a 
    massive amount of OSS and infrastructure, and fixes 
    Ruby's threading.

Being faster than MRI on some tests doesn't say much because from a performance standpoint MRI is a piece of shit.

If you're looking for a good reason for why Rubinius is important - JRuby cannot innovate and as Ruby will see progress, JRuby is bound to stagnate.

For example, continuations are really useful in many contexts, yet JRuby has no chance to actually implement continuations with decent performance overhead. Also, the Refinements proposal for Ruby 2.0 is a bitch to implement on JRuby. Even the Fibers in Ruby 1.9 come with a lot of overhead.

The reason for that is because JRuby inherits all the JVM's flaws. The JVM was designed for Java. The optimizations it makes function best in the context of Java. The type system is the one from Java and working around it is extremely painful. The garbage-collector itself is designed for Java. It has rough limitations on what it allows and what it doesn't allow. And when I'm saying Java, I'm saying Oracle's Java SE, or OpenJDK, not Android, not Java ME. And considering that Apache Harmony does not have the same JIT-ing characteristics of Oracle's Java SE, while I haven't seen any benchmarks I'm willing to bet the performance is much worse.

JRuby may shine among the current bunch of VMs, but that doesn't say much, because on top of the JVM in its current incarnation (including the invokedynamic additions) you'll never be able to achieve the performance Smaltalk was capable of.

If you care about Ruby as a language, caring about a VM like Rubinius is a no-brainer.

How can you say that JRuby can't innovate? JRuby is far from stagnating.

Continuations are almost never used, and in the rare cases where they are used they are almost always more straightforwardly replaced by non-continuation alternatives. FWIW, Rubinius doesn't support continuations either. It may some day...and so may the JVM.

Refinements will be easy to implement in JRuby. I've implemented prototypes of it in hours of effort. You don't know what you're talking about.

Fibers perform well in JRuby, but necessarily are implemented with native threads. There's work to add full VM-level coroutines in Java 8, and you can build versions of OpenJDK with coroutine support already. Once that's there, we will have substantially faster Fibers than Ruby 1.9.

JRuby supports all of Ruby's class structures and features atop the JVM. The JVM's type model does not hinder us implementing Ruby's class model.

The JVM optimizes calls; Ruby makes lots of calls. The JVM does an outstanding job of optimizing Ruby code in JRuby, and invokedynamic is already making small Ruby benchmarks in JRuby run within a few * the speed of an equivalent Java implementation. That's incredible. I've actually sat and read the assembly code Hotspot outputs and worked steadily to remove as much overhead as possible, with or without invokedynamic. I guarantee you the JVM is going to optimize Ruby like gangbusters. You don't know what you're talking about.

I'm not sure what Smalltalk performance you're talking about. No Smalltalk implementation has managed to approach the performance of current JVMs, and JRuby is starting to approach the performance of Java when using invokedynamic.

If you care about Ruby as a language, supporting many implementations and caring about all of them is a no-brainer. Slagging off one implementation you obviously have no correct facts about shows you don't care about Ruby as much as you harbor bigotry against one implementation.

Headius, you're awesome and I'm honored that you replied to my stupid rant.

My reply was meant for people that questioned a project like Rubinius when there is JRuby around. And you're right, I only have a very high-level overview of the problems you're encountering, mostly being just educated (or maybe not) guesses.

The reason for my rant is that Rubinius is awesome too and I would rather see Rubinius replace MRI as THE reference implementation - since it's a more flexible environment built from scratch, people will be able to experiment with features more easily.

I do however object to one thing you said - continuations are awesome and I'm sad they got pulled from Rubinius.

Reply on news.ycombinator.com