Slashdot Mirror
Is Ruby On Rails Losing Steam?
itwbennett writes: In a post last week, Quartz ranked the most valuable programming skills, based on job listing data from Burning Glass and the Brookings Institution. Ruby on Rails came out on top, with an average salary of $109,460. And that may have been true in the first quarter of 2013 when the data was collected, but "before you run out and buy Ruby on Rails for Dummies, you might want to consider some other data which indicate that Rails (and Ruby) usage is not trending upwards," writes Phil Johnson. He looked at recent trends in the usage of Ruby (as a proxy for Rails usage) across MS Gooroo, the TIOBE index, the PYPL index, Redmonk's language rankings, and GitHut and found that "demand by U.S. employers for engineers with Rails skills has been on the decline, at least for the last year."
Why is the parent modded down?
It's a very accurate description of real world Ruby on Rails apps.
Many adopters have been badly burned by this software, and the people who pushed it.
Failed projects, slow and broken apps, and fleeing developers are the hallmarks of Ruby on Rails.
It's much worse than Java was in the early 2000s, or C++ in the 1990s, or C and COBOL before that.
Ruby on Rails sounds great, until you try to use an app written in it, or worse, until you have to deal with a Rubyist. Then everything tends to go to hell.
Yeah, Ruby remains slightly slow because we trade code clarity for speed. The speed and memory usage have both improved drastically over the years, to where now performance is quite good. Not leading, of course. Because only optimization and changes that retain simplicity are used. We don't care about runtime speed, though we increase it when we can do so without giving anything up. What matters more is that we can scale horizontally well, and maintain portability without a lot of repetition and platform-specific gobblygook.
Ruby has an awesome C API, where everything in "Ruby" is also available in C, and so something that needs tight loops and bare-metal whatever, we can do that, and still have a high level interface to whatever we did. We can do the hard parts in C, and still have the app logic that ties it together in Ruby. So you don't even hit a wall where "this software should be in a different language," or "this tool doesn't work for this job." Instead you get, "this class should be implemented in C."
So however fast the C compiler's code is, our code can be that fast if we need it to be. And the Ruby interpreter can remain optimized for readability and ease of bug-fixing. It is like having a whole toolbox and being allowed to use more than one tool for a job. A lot of languages, you choose a tool from the toolbox, and now you have build everything with it, with the only ways around that involving networked interfaces.