8 ms·

I'm going to lose a lot of karma of this one, but here we go. The organizations I know of that have switched from Ruby to Java have done so for the following re

I'm going to lose a lot of karma of this one, but here we go. The organizations I know of that have switched from Ruby to Java have done so for the following reasons: 1) Performance. The JVM simply scales better, it is more cost effective in the datacenter. Without mentioning names, I know of significant Silicon Valley darlings that spent huge sums trying to scale Ruby, got crushed, and eventually ripped-and-replaced the backends with Java. 2) Skill Availability. There are 7+ million Java programmers, it is easier to hire Java programmers. 3) Tool Availability and Maturity. I think Ruby is a fine language, but I see it like PHP, great for rapid prototyping and productivity in the small, but it's version 1 for the lean startup or for the corporate departmental app. Version 2 is Java, C#, etc using the UX and product feature lessons learned from the Ruby prototype. IMHO, Node.js is the new Ruby. It has the benefit of having the same language on the client and the server, but once again, it's going to run into similar scalability issues when large organizations try to use it. I think we're going to run into the same issues, of it becoming a cool bandwagon, the platform being stretched to its breaking point, followed by the realization that there are serious problems.

tonyedgecombe 13y ago
I think a bigger change is the JVM and .Net don't suck so much now. There are interesting languages like Scala and Groovy on the JVM and frameworks like Play and MVC on .Net that make development less painful.
- danieldk 13y ago
  I think a bigger change is the JVM and .Net don't suck so much now. Frankly, JVM hasn't really sucked since it got a JIT compiler (J2SE 1.2, 1998) or if you prefer the switch to HotSpot as the default VM (J2SE 1.3, 2000).
blueblob 13y ago
I guess JRuby is trying to address the first point and they wouldn't have to retrain their staff. I don't know how popular JRuby is but it runs on the JVM.
Argorak 13y ago
Most of these stories also contain a lot of "we used a monolithic approach first and then split it up". A lot of companies I know kept their frontends in Rails, because its frontend tooling is really good. But you'll never write the big backend processing part in Rails. Also, this is a question of resources. Once your first version succeeds, you suddenly have the funds to build a complex version where you care about all the small details. Ruby is a _very good_ language as long as you are in the "I don't need to tune all the details phase".
- spullara 13y ago
  Twitter got a huge performance and efficiency boost even rewriting the front end on the JVM (in Scala).
  - Argorak 13y ago
    Twitter is a one-in-a-thousand company with traffic amounts that most of us here will dream of ever achieving. Even the more people that don't take specific interest in running large scale deployments. Even writing you frontend in Java first would (most likely) not have helped you coping with the new-found challenges in that heights.
    - spullara 13y ago
      Perhaps on the efficiency side. On the performance side it would be true even on a small site (unless it was all static, cached content). http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
    - danieldk 13y ago
      Twitter is a one-in-a-thousand company with traffic amounts that most of us here will dream of ever achieving. And not every low-traffic site is simple CRUD. If you do image processing, applying machine learning, natural language processing (or a thousand other things that are CPU intensive), it's nice that you can directly use one of the many high-performance libraries available in the Central Repository in your webservice.
reuven 13y ago
As I wrote elsewhere in this thread, I don't think that people are leaving Ruby in the droves that the author claims. Ruby isn't dying, and Rails isn't dying, at least not right now. However, the author does point to problems in Ruby's performance and maturity that are problems and issues -- if not immediately, then down the road. Your point about how people are leaving Ruby in favor of people, tools, and performance in the Java world is a good one. I would like to think that JRuby is a good option for such people, but maybe not. I found the author's ideas for modernizing Ruby to be interesting. I didn't agree with all of them, but at least he's trying to hash out some possible ways in which Ruby could improve. This sounds like a wish list for Ruby 3.0, though -- interesting ideas that would break compatibility, and that will take a while to implement. Perhaps his work, and that of Rubinius, could show us the way forward to such a new version.
- bhauer 13y ago
  JRuby, at least in my experience, has not yet delivered performance in line with my expectations of a JVM-hosted language. In my opinion, performance is by a huge margin the chief reason I do not begin new projects on Ruby. I would rather defer performance tuning efforts and scale complexity until much later in projects' life, rather than immediately following launch when I have 100 concurrent users hitting the application.
marcocampos 13y ago
I don't know why people keep complaining about Ruby's (MRI) speed. Yes, it's not that fast but for most programmer's doing web development it doesn't matter. Remember, you are (probably) not writing the next Twitter/Facebook/whatever. You are (probably) writing a boring LOB web application. Not everyone is working on a startup trying to peddle their stuff to a zillion users and getting hammered in the process. If you ever get to Twitter/Facebook/whatever size no out-of-box solution is going to work. You'll end up doing what Twitter did which is re-architect all their infrastructure/code and tune all their stuff as much has possible. Ruby's issue IMHO is that it has always been a Rails-centric community/ecosystem and never had the change to grow beyond that. It's still largely used to write web stuff and nothing else. Python, which is a "similar" language, has a much healthier and more diverse ecosystem being used in things like scientific computing or computer vision. If you want to make Ruby better, grow beyond the web application ecosystem and make it more diverse.
- Argorak 13y ago
  I agree with the Rails-centrism issue. Even alternative web frameworks have a hard time in the Ruby world. I disagree with the assumption that Ruby is web only. E.g. Chef and Puppet are huge efforts that have no direct connection to frontend web, both written in Ruby. Vagrant as well. Ruby is big in the infrastructure world.
  - marcocampos 13y ago
    What about game framework, computer vision, scientific computing, robotics, etc? I'm sure you can come up with examples for each of these but most are either dormant/abandoned or simply non-existant. As for infrastructure, yes Chef and Puppet are big in the startup world but I know a lot more companies using Python or Java for that.
    - Argorak 13y ago
      Does it help that I know far more companies using Chef and Puppet for that then Python and Java?
mcantelon 13y ago
>IMHO, Node.js is the new Ruby That seems a bit apples-to-oranges to me. The degree of hype is similar, yes, but other than that they seem like different animals. Ruby started slow (performance-wise), with memory leaks (that were denied at first), and was predominantly a community development. Node.js is running on top of V8, which is mature, performant, and backed by Google.
- briantakita 13y ago
  Plus it's evented so it's not really I/O bound, which makes it great as a service glue. Also, node.js with browserify & grunt makes for a great front end packaging & dependency tool.
  - mbillie1 13y ago
    > Also, node.js with browserify & grunt makes for a great front end packaging & dependency tool. This reminds me of "homebrew is a great packaging/dependency tool, it's basically as good as apt/yum/pacman"
  - vidarh 13y ago
    Ruby / MRI has for the most part been evented internally. It's how Ruby got away with green threads until 1.9.x; it's just largely hidden from the developer (until you try to call badly behaved C extensions...).
- mbillie1 13y ago
  V8 was first released in 2008 - and while it is awesome, "mature" sounds like a bit of a reach...
colinza 13y ago
"Skill Availability"... riiight. You know, one of these days this argument might catch on in other industries. For instance you go to the doctor and say "Doctor, I have a sore throat" and the doctor replies "Well, you might need your tonsils removed, but in order to do that we'd need to hire competent surgeons - how about we just punch you in the face until you forget about your throat"
- Afton 13y ago
  How is that relevant? You can solve the same problems in Java as you can in Ruby. An ENT surgeon is not interchangeable with a physical therapist.
  - colinza 13y ago
    You're clearly missing the boat by a mile here. The skill of developing software is transferable to different languages. Choosing a language for its skill availability is saying that you're too lazy to hire developers competent enough to learn a new language in a short space of time. If you're hiring people who can/will only write code in $language then there's something wrong with your hiring policy, or there'd be no reason for multiple languages to exist. Also you're flat out wrong about solving the same problems in different languages. It may be possible to solve all problems in Java or Ruby, but it is not possible to solve them in the same way - or more specifically the best, most economical or most maintainable way. To bring skill into the equation means no one should ever have written anything in Erlang because few people could write Erlang - but people do, because competent software engineers can learn Erlang.
qwerta 13y ago
I believe Node.js has solid technical foundations and it will not run into same troubles as Ruby or PHP. There are millions poured into JS research, Ruby never had decent GC or JIT. Also Node.js code base and unit tests are solid, not like client side JS. Also there are modern strongly typed languages which compile into JS and run just fine on Node.JS. This solves code-base scalability for large teams..
- mbillie1 13y ago
  I agree that Node.js is technically solid, but the Ruby/Rails code bases and communities have an immeasurably larger and more mature testing culture than JS/Node... and "modern strongly typed languages compiling to JS" does not by any means solve code-base scalability problems for large teams. That claim is simply false. There are boatloads of experienced Java developers. The people who tend to write "strongly typed languages compiling to JS" tend to write those languages, and not JS. To be clear: the web would not be what it is without JS, and Node is a fascinating and innovative thing. I disagree that there are loads of people who are experienced in C/C++ are champing at the bit to go write Node. The Java/C# talent pool is massively larger than the non-frontend JS talent pool at this time, and the C/C++ talent pool is largely otherwise occupied. That could change... but it hasn't changed yet. The HN/startup scene is not representative of the software industry at large, and a lot of people writing these "languages that can compile to JS" are part of the industry at large.
  - qwerta 13y ago
    All I am saying is that Node.JS has solid foundation to support huge community growth. For me as Java/Scala programmer Node.js is appealing for reasons described above. RoR usually means troubles and I try to avoid it.
- ebonfortress 13y ago
  V8 is backed up by Google, I guess that's pretty big deal.
jcroll 13y ago
PHP has HHVM, Symfony, and Composer; it does not suffer from any of these problems. Ruby is dying, PHP is the future.
stock_toaster 13y ago
> IMHO, Node.js is the new Ruby. It has the benefit of > having the same language on the client and the server, > but once again, it's going to run into similar > scalability issues when large organizations try to use > it. I think we're going to run into the same issues, > of it becoming a cool bandwagon, the platform being > stretched to its breaking point, followed by the > realization that there are serious problems. I think Elixir[0] may be the new hyped language. PragProg seems to be positioning[1] themselves[2] for a hype cycle on it, at the very least. [0]: http://elixir-lang.org [1]: http://pragprog.com/magazines/2013-06/programming-elixir [2]: http://pragprog.com/book/elixir/programming-elixir
- dingdingdang 13y ago
  No matter the whole hype cycle I do actually reckon Elixir is positioned to be the new leader on the programming-web-front: being underpinned by Erlang means it is the ONLY platform/language out there so far with super solid scalability to rival Java AND a light/novel way of programming. That being said I'm personally doing fine with newer versions of PHP (which for my purposes are solid and fine when backed by best practices and prepared sql statements!)
thatthatis 13y ago
Is it reasonable to paraphrase what you're saying as: When developers are more expensive than servers, rails makes sense. When servers are more expensive than developers (because of scale), Java/c# start to make sense.
- habitue 13y ago
  Or because you straight don't need an army of super capable developers once an organization is large. You need people keeping the lights on and maintaining the momentum
ultimoo 13y ago
>> PHP is great for rapid prototyping A few of the worlds most trafficked websites use PHP is production: wikipedia, facebook, wordpress, and hundreds of other bb forums.
ebonfortress 13y ago
Yes, Node.js is the new Ruby on Rails. It's amazing how EventMachine and other similar frameworks failed to gain traction.

tonyedgecombe 13y ago

I think a bigger change is the JVM and .Net don't suck so much now. There are interesting languages like Scala and Groovy on the JVM and frameworks like Play and MVC on .Net that make development less painful.

danieldk 13y ago
I think a bigger change is the JVM and .Net don't suck so much now. Frankly, JVM hasn't really sucked since it got a JIT compiler (J2SE 1.2, 1998) or if you prefer the switch to HotSpot as the default VM (J2SE 1.3, 2000).

blueblob 13y ago

I guess JRuby is trying to address the first point and they wouldn't have to retrain their staff. I don't know how popular JRuby is but it runs on the JVM.

Argorak 13y ago

Most of these stories also contain a lot of "we used a monolithic approach first and then split it up". A lot of companies I know kept their frontends in Rails, because its frontend tooling is really good. But you'll never write the big backend processing part in Rails. Also, this is a question of resources. Once your first version succeeds, you suddenly have the funds to build a complex version where you care about all the small details. Ruby is a _very good_ language as long as you are in the "I don't need to tune all the details phase".

spullara 13y ago
Twitter got a huge performance and efficiency boost even rewriting the front end on the JVM (in Scala).
- Argorak 13y ago
  Twitter is a one-in-a-thousand company with traffic amounts that most of us here will dream of ever achieving. Even the more people that don't take specific interest in running large scale deployments. Even writing you frontend in Java first would (most likely) not have helped you coping with the new-found challenges in that heights.
  - spullara 13y ago
    Perhaps on the efficiency side. On the performance side it would be true even on a small site (unless it was all static, cached content). http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
  - danieldk 13y ago
    Twitter is a one-in-a-thousand company with traffic amounts that most of us here will dream of ever achieving. And not every low-traffic site is simple CRUD. If you do image processing, applying machine learning, natural language processing (or a thousand other things that are CPU intensive), it's nice that you can directly use one of the many high-performance libraries available in the Central Repository in your webservice.

reuven 13y ago

As I wrote elsewhere in this thread, I don't think that people are leaving Ruby in the droves that the author claims. Ruby isn't dying, and Rails isn't dying, at least not right now. However, the author does point to problems in Ruby's performance and maturity that are problems and issues -- if not immediately, then down the road. Your point about how people are leaving Ruby in favor of people, tools, and performance in the Java world is a good one. I would like to think that JRuby is a good option for such people, but maybe not. I found the author's ideas for modernizing Ruby to be interesting. I didn't agree with all of them, but at least he's trying to hash out some possible ways in which Ruby could improve. This sounds like a wish list for Ruby 3.0, though -- interesting ideas that would break compatibility, and that will take a while to implement. Perhaps his work, and that of Rubinius, could show us the way forward to such a new version.

bhauer 13y ago
JRuby, at least in my experience, has not yet delivered performance in line with my expectations of a JVM-hosted language. In my opinion, performance is by a huge margin the chief reason I do not begin new projects on Ruby. I would rather defer performance tuning efforts and scale complexity until much later in projects' life, rather than immediately following launch when I have 100 concurrent users hitting the application.

marcocampos 13y ago

I don't know why people keep complaining about Ruby's (MRI) speed. Yes, it's not that fast but for most programmer's doing web development it doesn't matter. Remember, you are (probably) not writing the next Twitter/Facebook/whatever. You are (probably) writing a boring LOB web application. Not everyone is working on a startup trying to peddle their stuff to a zillion users and getting hammered in the process. If you ever get to Twitter/Facebook/whatever size no out-of-box solution is going to work. You'll end up doing what Twitter did which is re-architect all their infrastructure/code and tune all their stuff as much has possible. Ruby's issue IMHO is that it has always been a Rails-centric community/ecosystem and never had the change to grow beyond that. It's still largely used to write web stuff and nothing else. Python, which is a "similar" language, has a much healthier and more diverse ecosystem being used in things like scientific computing or computer vision. If you want to make Ruby better, grow beyond the web application ecosystem and make it more diverse.

Argorak 13y ago
I agree with the Rails-centrism issue. Even alternative web frameworks have a hard time in the Ruby world. I disagree with the assumption that Ruby is web only. E.g. Chef and Puppet are huge efforts that have no direct connection to frontend web, both written in Ruby. Vagrant as well. Ruby is big in the infrastructure world.
- marcocampos 13y ago
  What about game framework, computer vision, scientific computing, robotics, etc? I'm sure you can come up with examples for each of these but most are either dormant/abandoned or simply non-existant. As for infrastructure, yes Chef and Puppet are big in the startup world but I know a lot more companies using Python or Java for that.
  - Argorak 13y ago
    Does it help that I know far more companies using Chef and Puppet for that then Python and Java?

mcantelon 13y ago

>IMHO, Node.js is the new Ruby That seems a bit apples-to-oranges to me. The degree of hype is similar, yes, but other than that they seem like different animals. Ruby started slow (performance-wise), with memory leaks (that were denied at first), and was predominantly a community development. Node.js is running on top of V8, which is mature, performant, and backed by Google.

briantakita 13y ago
Plus it's evented so it's not really I/O bound, which makes it great as a service glue. Also, node.js with browserify & grunt makes for a great front end packaging & dependency tool.
- mbillie1 13y ago
  > Also, node.js with browserify & grunt makes for a great front end packaging & dependency tool. This reminds me of "homebrew is a great packaging/dependency tool, it's basically as good as apt/yum/pacman"
- vidarh 13y ago
  Ruby / MRI has for the most part been evented internally. It's how Ruby got away with green threads until 1.9.x; it's just largely hidden from the developer (until you try to call badly behaved C extensions...).
mbillie1 13y ago
V8 was first released in 2008 - and while it is awesome, "mature" sounds like a bit of a reach...

colinza 13y ago

"Skill Availability"... riiight. You know, one of these days this argument might catch on in other industries. For instance you go to the doctor and say "Doctor, I have a sore throat" and the doctor replies "Well, you might need your tonsils removed, but in order to do that we'd need to hire competent surgeons - how about we just punch you in the face until you forget about your throat"

Afton 13y ago
How is that relevant? You can solve the same problems in Java as you can in Ruby. An ENT surgeon is not interchangeable with a physical therapist.
- colinza 13y ago
  You're clearly missing the boat by a mile here. The skill of developing software is transferable to different languages. Choosing a language for its skill availability is saying that you're too lazy to hire developers competent enough to learn a new language in a short space of time. If you're hiring people who can/will only write code in $language then there's something wrong with your hiring policy, or there'd be no reason for multiple languages to exist. Also you're flat out wrong about solving the same problems in different languages. It may be possible to solve all problems in Java or Ruby, but it is not possible to solve them in the same way - or more specifically the best, most economical or most maintainable way. To bring skill into the equation means no one should ever have written anything in Erlang because few people could write Erlang - but people do, because competent software engineers can learn Erlang.

qwerta 13y ago

I believe Node.js has solid technical foundations and it will not run into same troubles as Ruby or PHP. There are millions poured into JS research, Ruby never had decent GC or JIT. Also Node.js code base and unit tests are solid, not like client side JS. Also there are modern strongly typed languages which compile into JS and run just fine on Node.JS. This solves code-base scalability for large teams..

mbillie1 13y ago
I agree that Node.js is technically solid, but the Ruby/Rails code bases and communities have an immeasurably larger and more mature testing culture than JS/Node... and "modern strongly typed languages compiling to JS" does not by any means solve code-base scalability problems for large teams. That claim is simply false. There are boatloads of experienced Java developers. The people who tend to write "strongly typed languages compiling to JS" tend to write those languages, and not JS. To be clear: the web would not be what it is without JS, and Node is a fascinating and innovative thing. I disagree that there are loads of people who are experienced in C/C++ are champing at the bit to go write Node. The Java/C# talent pool is massively larger than the non-frontend JS talent pool at this time, and the C/C++ talent pool is largely otherwise occupied. That could change... but it hasn't changed yet. The HN/startup scene is not representative of the software industry at large, and a lot of people writing these "languages that can compile to JS" are part of the industry at large.
- qwerta 13y ago
  All I am saying is that Node.JS has solid foundation to support huge community growth. For me as Java/Scala programmer Node.js is appealing for reasons described above. RoR usually means troubles and I try to avoid it.
ebonfortress 13y ago
V8 is backed up by Google, I guess that's pretty big deal.

jcroll 13y ago

PHP has HHVM, Symfony, and Composer; it does not suffer from any of these problems. Ruby is dying, PHP is the future.

stock_toaster 13y ago

> IMHO, Node.js is the new Ruby. It has the benefit of > having the same language on the client and the server, > but once again, it's going to run into similar > scalability issues when large organizations try to use > it. I think we're going to run into the same issues, > of it becoming a cool bandwagon, the platform being > stretched to its breaking point, followed by the > realization that there are serious problems. I think Elixir[0] may be the new hyped language. PragProg seems to be positioning[1] themselves[2] for a hype cycle on it, at the very least. [0]: http://elixir-lang.org [1]: http://pragprog.com/magazines/2013-06/programming-elixir [2]: http://pragprog.com/book/elixir/programming-elixir

dingdingdang 13y ago
No matter the whole hype cycle I do actually reckon Elixir is positioned to be the new leader on the programming-web-front: being underpinned by Erlang means it is the ONLY platform/language out there so far with super solid scalability to rival Java AND a light/novel way of programming. That being said I'm personally doing fine with newer versions of PHP (which for my purposes are solid and fine when backed by best practices and prepared sql statements!)

thatthatis 13y ago

Is it reasonable to paraphrase what you're saying as: When developers are more expensive than servers, rails makes sense. When servers are more expensive than developers (because of scale), Java/c# start to make sense.

habitue 13y ago
Or because you straight don't need an army of super capable developers once an organization is large. You need people keeping the lights on and maintaining the momentum

ultimoo 13y ago

>> PHP is great for rapid prototyping A few of the worlds most trafficked websites use PHP is production: wikipedia, facebook, wordpress, and hundreds of other bb forums.

ebonfortress 13y ago

Yes, Node.js is the new Ruby on Rails. It's amazing how EventMachine and other similar frameworks failed to gain traction.