15 ms·

(1) I think the rub isn't so much that they're bashing Ruby as it seems like rather than evaluating all their options, they just jumped ship to some random unpr

(1) I think the rub isn't so much that they're bashing Ruby as it seems like rather than evaluating all their options, they just jumped ship to some random unproven technology for whatever reason. They then turn around and say "well we switched because Ruby didn't do what needed" (but check out my book on the language that does!!). It makes one think they don't know if it did or didn't, since JRuby would've solved a goodly number of their problems (probably; we'll never really know). Just like when they wrote Starling, they seemed to have just decided to hack something out rather than make a reasoned technical decision. (2) Yes, but JRuby and Ruby 1.9 both handle those problems much better. Moot argument. (3) So rather than picking an "unproven" technology (by some measure of unproven), they write something completely new in a comparatively immature programming language. Yup. Much better choice. And since when did JVM compatibility matter? The reason they chose the JVM was good threading and so on, but Erlang has that same support. It wouldn't be introducing a third "exotic" platform, but a second, different platform. Of course, I'm saying this stuff from an outside perspective. I'm hoping he elaborates on his blog, because I would really be interested to hear a more technical explanation of their decisions.

tptacek 18y ago
I really think you're going to lose this argument. You're defending a blog post that says that Kestrel was a far worse choice than a single-developer C project with no major success stories. I don't think, and I don't believe that you think, that Scala is as likely to be a failure mode for Twitter as MQ is. However immature Scala is --- and I'm not using it --- the Scala runtime is absolutely rock solid. I'm sure that's true of JRuby as well, but the comparison isn't between JRuby and Scala, it's between MRI and Scala, and for a company that tolerated high-volume messaging servers in MRI, we both know Scala is going to be like shangri-la by comparison.
- jeremymcanally 18y ago
  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).
  - ankhmoop 18y ago
    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.

tptacek 18y ago

I really think you're going to lose this argument. You're defending a blog post that says that Kestrel was a far worse choice than a single-developer C project with no major success stories. I don't think, and I don't believe that you think, that Scala is as likely to be a failure mode for Twitter as MQ is. However immature Scala is --- and I'm not using it --- the Scala runtime is absolutely rock solid. I'm sure that's true of JRuby as well, but the comparison isn't between JRuby and Scala, it's between MRI and Scala, and for a company that tolerated high-volume messaging servers in MRI, we both know Scala is going to be like shangri-la by comparison.

jeremymcanally 18y ago
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).
- ankhmoop 18y ago
  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.