Thoughts about software development

Has Ruby on Rails become mainstream?

A friend of mine recently contacted me about my entry called Why Ruby on Rails won’t become mainstream and is asking me if I’m still of this opinion. I thought that revisiting this topic would be a good way to start the year, so here goes…

My first reaction was to go to monster.com and dice.com and check out a few numbers. Here are some preliminary results:

dice.com

monster.com

Ruby

632

562

Ruby on Rails

243

190

Java

14996

> 5000

J2EE

7313

4380

.net

11905

[Error]

C#

6886

> 5000

PHP

2170

2216

These numbers are fairly consistent but since the data sample is relatively low, you are welcome to dismiss them as not representative, but that won’t stop me from elaborating a bit more on the subject…

My overall impression is that Ruby on Rails has settled in a niche that is probably not marginal any more but is still a far cry from being any close to mainstream. I’m also betting that this mindshare will probably not grow by much in the coming year, so it will be interesting to revisit this prediction in one year from now.

At any rate, I would say that my concern with Ruby on Rails has shifted in a few subtle ways. The problem is no longer that it won’t become mainstream but that it suffers from a few blemishes and flaws that still make betting an entire business on it a risky call plagued with limits that even the most determined entrepreneur will have a hard time overcoming.
Here are a few random thoughts:

From a developer’s perspective, finding a job in Ruby or Ruby on Rails is probably not extremely hard, although it’s still much harder than finding one in Java or C#, but it seems to me that the very fact that Ruby is a niche is what allows the few developers that are fluent in it to locate paying jobs with reasonable salaries (at least, it seems to be the case around me, but I live in San Francisco so my personal data sample is probably a bit biased).

The lack of powerful IDE functionalities such as refactoring for Ruby (and Ruby on Rails is much worse off) is still a concern and limits tremendously the pool of developers that Ruby can tap into (see below for some elaboration on this topic).

Let’s suppose we can rank developers on a scale from A+ to G-, G- being “terrible” and A+ being “stellar”, I claim that in order to implement a similar product, you will need a team of B+ Ruby developers while a similar result could be achieved with a team of C+ Java developers.

This echoes one of the points I made in my original article: Ruby on Rails is sometimes too clever and too magical, and it takes quite a bit more of intellectual effort to understand how it works than it takes to understand how a servlet or even an advanced framework like WebWorks works. I also suspect that in order to be efficient with RoR, you need to practice it every day. Stop using it or abandon a certain section of your code for a few months and I’m afraid that the combination of Ruby and RoR’s sometimes overbearing cuteness will lead you to a lot of hours trying to understand how your own code works (RoR’s tendency to have a lot of implicit defaults or source files in different directories magically connected to each other doesn’t help).

Let’s go back to the developer quality argument: not only do you need smarter developers when you’re writing a Rails application, there also happens to be *less* of these smart developers, since the pool of Ruby programmers is dwarfed by that of Java.

In short, you need better people picked from a smaller pool.

This is potentially a deadly hurdle for start ups that have passed the prototype stage and are now trying to grow their business and their product. They can no longer afford to be picky: whenever they find someone who appears to be good enough, they need to hire him, regardless of any other potential flaws.

And to conclude this brief opinion piece on something even more gloomy, Zed Shaw, the author of Mongrel, a very popular Ruby framework and someone who’s highly respected in the Ruby community (albeit probably not for much longer), posted this very morning a scathing summary of his experience with the Ruby on Rails community. It’s not pretty, it’s very abrasive and probably laced with as many inaccuracies as correct statements, but I’m pretty sure a lot of Rails programmers will relate to some of the anger and frustration that Zed feels.

So do I still think that Ruby on Rails won’t become mainstream? Yes. Definitely. And even if I’m wrong, it will take many years before Ruby on Rails can come even close to the numbers displayed by other popular languages and web frameworks.

This entry was posted on January 4, 2008, 9:27 am and is filed under General. You can follow any responses to this entry through RSS 2.0.
Both comments and pings are currently closed.

I was speaking to the co-founders of a NYC-based startup a couple of weeks ago. They mentioned that they initially wanted a ‘senior’ Ruby On Rails developer on their team (the term ‘senior’ meant 3+ years experience with Ruby, 2+ years experience in Rails), but they couldn’t find anyone with those qualifications. And it’s very true: I’d say 99% of the people with tons of experience in a niche market like Rails are definitely employed already. So not only is it difficult to get a job on Rails, it’s also tough to find one if you’re an employer.
Right now, Rails is still gaining a lot of attention, and seemingly hasn’t stopped since it was released to the public. Will it continue this way? I think so. There are a lot of problems with Rails right now, but if you’ve noticed, changes come so rapidly that today’s problem with definitely be solved sooner rather than later. With these changes, Ruby and Rails will most likely become ‘mainstream’.

No. ROR will not become mainstream.
You need superstars for ROR projects and the world does not have enough of them.
A language needs to make the average guy productive to become mainstream and i’m afraid ROR has a lot of magic behind the scenes which the average guys will not understand.

I think I would disagree on the IDE reason – you normally dont need an IDE for ruby.
If you refer to documentation about methods i.e. for Rails, then there are already IDEs that solve this (plus it wouldnt be hard to use i.e. ruby-gnome with it… i favour distributed IDEs with integrated wiki so that a team can tag notes and examples to these things easily)

This post seems to be by a poster in a non-technical background. The points you raise are valid, however, here’s the single biggest Rails turn off:
Deployment and scaling is absolutely horrible. Rails hides so much complexity, and makes the code for the developer so clean, that the real backend, the stuff that really happens behind the scenes, quickly becomes complex, leading to slow applications. Also, keeping up a Rails server is hard. Frequent updates, lots of gems (packages) to keep up too, making sure that nothing breaks.
Rails absolutely suffers in that regard.
I’m working with Python now, and it is beautiful how fast and stable everything runs once it’s done.

Wow, you wrote a very good book… for someone “in a non-technical background”. :o)
I’m surprised you didn’t comment about the apparent JRuby push from Sun. I’d expect if RoR were to become mainstream, then that might be one of the catalysts.
After all – RoR users don’t come from nowhere. Most of them presumably have experience in other languages/frameworks. If Sun mention JRuby in front of Java developers more often, then the language (and perhaps the framework) may get more attention.
(Why do I have to enter the captcha once to preview, and once to post?)

@mart I agree completely with the JRuby comment.It seems that JRuby and NetBeans are always conveniently left out of these arguments because they addressing every single complaint about why Ruby won’t become mainstream. Look at the number of daily builds that are done by the JRuby/NetBeans teams – it is remarkable and won’t be long before all issues are resolved.
I think your third point is ludicrous – it is fact less and is a waste of time to even comment about it.
Do you think that Ruby is the only language that has voodoo behind it – voodoo can be done in Java as well, it is just so complex that only a very very small minority of brilliant developers dare venture into that water. In Ruby (and Python) on the other hand these things are relatively easy to do and therefore done more often – a blessing or curse – who knows.
You should also use the TIOBE index when trying to suppose the future. It clearly indicates that dynamic languages are on the rise and static languages are on the fall.
Lets take one more look at the Monster Numbers:
Ruby + Rails + RoR = 1124
Python + Django = 1578
Hmmmm – does this mean Python is also doomed? I hope not, I hope that at least one of these two or JRuby makes it into the mainstream.
@Robert “No, and hopefully it won’t.”
Geeze dude – would you prefer we all still be using assemblers?

I wonder if all of those Java developers are being hired to support all the Java code that has been in existence forever rather than creating new applications. Statistics without context are rather meaningless, and can be skewed regardless. Also, there are a lot of large “mainstream” companies that use Ruby on Rails, they just don’t vocalize it.

I think that it is quite easy to get a job doing Rails.
Dennis Martinez is spot on. Companies are trying to find Rails folks and it is bloody hard to find anyone!
So, if you are a developer you can get a job doing Rails. The problem is that if you are going to do a Rails startup, you need to realize that it is hard to find people, and that you may be looking at retraining.

Maybe the pool of Ruby developers doesn’t break down on the A-G scale the same way the Java one does. Perhaps there are more A’s in the Ruby pool and more C’s in the Java pool. The different mindset required to deal with the extensive use of “convention” would be a reasonable cause here.
If that were the case, and I suspect it is, the statement about “better people picked from a smaller pool” wouldn’t mean quite as much.

Ruby on Rails did not destroy Java. It destroyed a bunch of annoying web frameworks (I will not name them) that can be compared to a Rube Goldberg machine
Why do you need Ruby on Rails when you have Mentawai?
book.mentaframework.orghttp://www.mentaframework.org
-Sergio

On medium and long term, what matters is whether the developers you recruit are smart. It does not matter that much whether they are proficient in RoR to make a valuable contribution to your organization.

I get the impression from Tor Norbye’s blog (see blogs.sun.com/tor/category/Ruby) that NetBeans is actually getting to be quite a decent Ruby IDE, with refactoring, contextual completion, documentation tooltips, quick-fixes, and all those sorts of bells and whistles us spoiled Java programmers have come to expect out of the box. So much so that it’s almost got me tempted to finally dive into Ruby / Rails, except that I don’t have any web apps I need to build. Anyone tried it?

As an experienced Java developer who’s just now learning Rails, a lot of this rings true to me.
There are a couple of really troubling problems I’ve seen thus far as a novice Rubyist but not a novice programmer.
1- Traceability. Due to the magic of yield blocks and the untyped nature of everything, it can be really hard to know what the type of the thing being yielded is, and how to use it. If there were consistantly good levels of documentation this might be fine, but…
2- False Polymorphism In the absense of strong typing, many methods in rails have polymorphic behavior that is subtle and non obvious without sufficient documentation. For example an update methods that takes (object, map_of_updates) and ALSO (list_of_objects, identical_length_list_of_maps_of_updates). Yes, that is documented, but without digging into the details of the documentation I’d never guess that the alternate behavior was present.
3- Too clever one liners. The iterators make a lot of magic possible. Not everything that’s possible with them is particularly readable to less experienced developers. The emphasis on one-liners can lead to almost perlishly incomprehensible code.
4- Inadequate documentation tools. The inclusion of modules into classes brings a lot of ‘magic’ looking behavior that doesn’t seem to be well documented in any of the htmlified rails documentation sets I’ve seen. Also, the standard documentation layout is almost unusably badly laid out.
Some of these seem like indictments of Ruby, but really they aren’t, because Ruby by itself enables but doesn’t demand the incredible magic that rails leverages. But every damn thing you remove from being explicit in the code becomes something that you simply have to memorize and know in advance is there. Which puts the extra strain on going from a novice to intermediate developer.
Oh, and I skipped the biggest problem with rails
5- Obnoxious advocates. I’ve been poking around the flamewars and discussions on RoR for a few months now, and it’s increasingly clear that the most genteel and polite criticism that “Rails doesn’t do X the way that I’d like it” draws down obnoxious levels of defensive, retaliatory lashing out.
blog.dreamhost.com/2008/01/10/rails-is-as-rails-does/
This exchange and the comments are illuminating on
this point. Dallas at Dreamhost appears to be simply suggesting that rails has been a pain for them to offer services for, and they’d like it if it were easier. It wasn’t an angry demand. It certainly wasn’t an indictment of the community. But many posters treated the complaints as if they were assaults on Ruby’s worth and DHH himself wrote mockingly that DreamHost should ‘wipe the wah-wah tears’ away. That’s just childish.
‘You’re not an important market sector, and I’m not interested in supporting you’ would have been how a grownup might have sent the same message. I think it’s a stupid message to send, but when the creator/leader/personality cult gets personal in response to gentle complaints, it’s not something that gives bystanders any sense of peace.
Also, every time a Railsist writes contemptuously about the Enterprise or the Mainstream, I want to smack him in the ear and tell him to grow up. Good software isn’t about movements, it’s about solving problems. And saying that you’re not interested in working on the big problems, or the hard problems, or the typical problems is fine, but it’s not something to take personal pride in.

I choose tools based on suitability to the task at hand AND how productive I can be with them… I could care less whether or not the mainstream adopts the same tools – in fact it might be preferable if they don’t!

Very thoughtful post. I have been following RoR for some time and tried building a few apps. However mainly work in the ASP.NET space for my day job.
Anyway I am giving some serious consideration to Google App Engine now. RoR seems tempting given my investment to date but wondering whether Google App Engine and Django maybe a better long term option?

I agree with your concerns in your original post, many of which have or are starting to be addressed.
The ruby version of Netbeans is a great IDE for Ruby/Rails development. I use it daily, the real feature an IDE brings, code completion. Using JRuby internally you get real code completion in Netbeans. JRuby in my opinion is what will make Ruby. There is a lot of work in the Ruby VM arena. Take a look at some of the up and coming ruby frameworks: Merb, Waves and Mack (plus others) – now featuring threading and much more modular [Rails’s mistakes].

Michael: Just to clear up a few things for you.
1- Traceability. This really boils down to your design, if you’re using yield statements to solve a specific problem, then you’re most probably barking up the wrong tree. Generally, yield serves to allow the calling code to do whatever they want, without caring about what is done.
3- Too clever one liners. In a rails app, clever one-liners belong to models/helpers where they can just as cleverly be hidden away and documented. I agree with you though that code like this can/will become incomprehensible.
5- Obnoxious advocates. Every language/framework has its fair share of these people =) I’m not defending DHH but Dreamhost is a pretty childish host as well, especially in how they handled one of their recent billing crisis. Plus, overcoming hurdles and solving problems like these are part and parcel of any business; Dreamhost will have to deal with it.
Also, I agree with you on how sucky documentation is for RoR. But look at the upside, sometimes being forced to look in the source code makes you learn to write better code (arguably).
Eduardo: I would disagree with you that RoR is easier than other frameworks therefore it requires less competent programmers. Looking at how things have become, C#/Java programmers are a dime a dozen and the bulk of them aren’t truly programmers. Yet they get by in their jobs, copy/pasting from codeproject (or through similar devices, bear with me).
This isn’t something you can do in Rails without running into a wall. The thing is, a lot of problems have already been solved by the ASP.net/Java/etc community whereas in RoR, you can sometimes find yourself dealing with a problem alone.
I would say that it’s easier to write a web app in RoR than ASP.net/Java if you were a competent programmer, but the lack of market penetration makes it harder for the below average programmer. Same goes for Python.

Cedric – did you actually read Zed’s post?
Anyone who pours that amount of energy into lambasting every soul who’s not in his current friend list has some serious issues. Frankly, why should we take any of what he has to say seriously? He’s one angry individual trying to smear nearly every person who has any connection to rails.
What is this, Jerry Springer for software engineers? Your reference to his post undermines your credibility.

It’s been said many times before “rails is no silver bullet”. It’s another tool in your toolset, and you can use it wrongly at your peril. You can also ignore it at your peril.
A big part of being a developer is about picking the right tools. If Rails seems suitable for a project, you’d be silly to ignore it, vice versa.
It doesn’t matter whether Rails becomes “mainstream” or not. What matters is if you’re willing to learn a new technology when you need to.

There are a few decent IDE out there:
– plugin for Eclipes
– NetBeans 6+, they have done great job
It’s not fair that you use the job number comparing with a technology itself. It’s just like you compare Windows with Linux, they all have various purposes. Especially, a company is less likely to use a open source code anyway.

An interesting observation I’ve had over the last few years:
Since the decline in the economy, there seems to be a new boom of startups as people like me who formerly worked at big firms reinvented themselves as entrepreneurs.

These startups seem much more eager to use newer, upstart technologies like Ruby on Rails, Python, and Node.js for their web infrastructure. In my opinion this has been a boom for Ruby in general, mainly at the cost of PHP (which still predominates).

This is my observation, and may be from too small of a sample size, so feel free to take it with a grain of salt, but I think there’s something to it.