5 ms·

Ok, this bit has left me confused. They were Java devs that liked ruby, they wrote applications in Ruby on Rails and the ruby apps were hitting limits so they

Ok, this bit has left me confused. They were Java devs that liked ruby, they wrote applications in Ruby on Rails and the ruby apps were hitting limits so they immediately started looking at other languages. But they don't mention the most obviously (to my mind) simple option. JRuby It is ruby (They like ruby). Most ruby apps can be run on JRuby with very very little changes (No need for a big rewrite) and it runs on the JVM with which they are familiar and it is very fast (and true multi-threading). Maybe they did look into it but I would have thought that would be #1 on their "We tried this but discounted it" list.

oscardelben 14y ago
I'd like to see some real benchmarks with a real app, but I doubt moving to jruby would bring the magnitude of improvement mentioned in the post.
pkulak 14y ago
In my experience, rewriting for JRuby is as much work as re-writing in a new language. Last I looked was a year or two ago, so it may have all changed, but it's not as simple as just moving your code over. Many really important gems don't work, or don't work properly.
- boundlessdreamz 14y ago
  The only gems that do not work are those which are not pure ruby. For the popular gems I think there have been rewrites. I haven't looked into JRuby but it has changed quite a bit in the last year from what I read
  - johnb 14y ago
    I don't think that's true. There are plenty of threadsafe gems with C extensions, and plenty of non-threadsafe pure ruby gems that mutate class/class-instance variable willy-nilly.
    - boundlessdreamz 14y ago
      gems with C extensions are not supported https://github.com/jruby/jruby/wiki/C-Extension-Alternatives https://github.com/jruby/jruby/wiki/C-Extension-Alternatives I forgot about thread safety in pure ruby gems but that is not a huge problem - https://github.com/jruby/jruby/wiki/Gems-known-not-to-be-threadsafe https://github.com/jruby/jruby/wiki/Gems-known-not-to-be-thr...
- ghostganz 14y ago
  That used to be the case, but a lot has happened in the last few years. Most of the time you'll be able to move a large Rails application to JRuby without any changes at all, except adding a Warbler config for deployment. We use JRuby for a one of our backend applications in production, but we develop them with plain MRI Ruby. Only real problem we've run in to was some of our badly performing (badly written) parsing code that ran even worse under JRuby.
pjmlp 14y ago
They also did not mention why they didn't try any other of the more performant implementations of Ruby.
- codygman 14y ago
  They probably needed a rewrite anyway, after learning more about the problem space they weren't happy with the api they'd made thus far. Go wasn't the only thing that made their new stack better, but you can bet that Go would have made it very difficult for them to achieve performance as bad as ruby gave them. That said, they are STILL using rails for the frontend stuff and Go for their more computationally intensive stuff IIRC. They still kept some of their rails code, for things that were easier to keep in rails without hurting performance.

oscardelben 14y ago

I'd like to see some real benchmarks with a real app, but I doubt moving to jruby would bring the magnitude of improvement mentioned in the post.

pkulak 14y ago

In my experience, rewriting for JRuby is as much work as re-writing in a new language. Last I looked was a year or two ago, so it may have all changed, but it's not as simple as just moving your code over. Many really important gems don't work, or don't work properly.

boundlessdreamz 14y ago
The only gems that do not work are those which are not pure ruby. For the popular gems I think there have been rewrites. I haven't looked into JRuby but it has changed quite a bit in the last year from what I read
- johnb 14y ago
  I don't think that's true. There are plenty of threadsafe gems with C extensions, and plenty of non-threadsafe pure ruby gems that mutate class/class-instance variable willy-nilly.
  - boundlessdreamz 14y ago
    gems with C extensions are not supported https://github.com/jruby/jruby/wiki/C-Extension-Alternatives https://github.com/jruby/jruby/wiki/C-Extension-Alternatives I forgot about thread safety in pure ruby gems but that is not a huge problem - https://github.com/jruby/jruby/wiki/Gems-known-not-to-be-threadsafe https://github.com/jruby/jruby/wiki/Gems-known-not-to-be-thr...
ghostganz 14y ago
That used to be the case, but a lot has happened in the last few years. Most of the time you'll be able to move a large Rails application to JRuby without any changes at all, except adding a Warbler config for deployment. We use JRuby for a one of our backend applications in production, but we develop them with plain MRI Ruby. Only real problem we've run in to was some of our badly performing (badly written) parsing code that ran even worse under JRuby.

pjmlp 14y ago

They also did not mention why they didn't try any other of the more performant implementations of Ruby.

codygman 14y ago
They probably needed a rewrite anyway, after learning more about the problem space they weren't happy with the api they'd made thus far. Go wasn't the only thing that made their new stack better, but you can bet that Go would have made it very difficult for them to achieve performance as bad as ruby gave them. That said, they are STILL using rails for the frontend stuff and Go for their more computationally intensive stuff IIRC. They still kept some of their rails code, for things that were easier to keep in rails without hurting performance.