Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not defending the post, but countering your points. If my points happen to line up with his opinions, then that's merely coincidence. There are a lot of MQ options out there, many of which I've used with great success (with Ruby no less). To argue that one of those is less acceptable than a home grown solution in Scala is, at best, dubious.

But you just danced around the real question: why not JRuby? Scala's runtime == JRuby's runtime. They're both JVM languages, and if they were to use JRuby, there wouldn't be some big crazy rewrite. The only difference would've been "jruby mq.rb" rather than "ruby mq.rb." That's the decision that hasn't really been explained.

Even further, I'm not sure why you're insinuating that I think they should write a message queue in MRI. Either use JRuby or use something else. I totally agree MRI is not acceptable for something like this (but 1.9 may be; I haven't tried it but its performance is only a hair slower than JRuby), but there are other ways to solve the same problem that don't involve rewriting tons of code (either by using JRuby or by using a proven, solid drop in replacement, possibly with an API shim if they really needed it).



JRuby is not a 1:1 mapping of a Ruby to Java bytecode -- there's significant additional book-keeping that must be done by JRuby's runtime (for example, maintaining the Ruby call frames).

In contrast, Scala maps to the JVM as closely as possible. Scala classes are Java classes -- Scala and Java are bidirectionally interoperable, and Scala's performance subsequently benefits.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: