Many developers now know that Ruby on Rails is one of the most important open source projects of our time. The engine behind the growth--intense productivity--is unmatched for frameworks with similar marketshare. While other frameworks boast impressive productivity, no other framework matches the impressive combination of technical innovation and marketshare.

Sounds like you are trying to flog yet another sliver bullet.

Ruby, and the flagship Rails framework, leads to dramatic productivity improvements, often approaching a factor of three to five for certain applications

Oh god you are. I'm assuming you've ready Mythical Man Month?

This is what loses people touting frameworks respect, the claim that it really is (honest) the silver bullet we've been looking for all these years.

Its like the Java argument, give me ten good Java guys and I'll do more than with the 100 average ones currently on the project (that is in MMM as well). Ruby currently has some very good people (lots like yourself being ex-Java) but has significant Application Management challenges and the perceived productivity gains will be dramatically less as you try to do the offshore project using Ruby.

Not so long ago the productivity of RoR was said to be at least a ten factor. Now, after some more experience was gained it came to "three to five for certain applications". That's more realistic :-].

Unlike the typical scripting language, early indications indicate that Ruby also should excel at longer term issues such as ease of maintenance, simplicity, and extensibility.

The Ruby on Rails framework has still more revolutionary features that have not yet been duplicated in Java frameworks.

Yeah, and Microsoft claimed .NET was 5x more productive than Java too. It's all BS.

I will "race" anyone in any language with any application domain. Not to prove that I'm better, but only to prove that any significant productivity factor is complete BS. Whether you win or lose, it won't be a factor of 5, 4, 3, or even 2. It will be 1.1, or 1.2 either way.

Or if you want, I'll setup and run the competition (because I doubt anyone else ever will). I know enough people on all the platforms to compete in such a thing, only to prove that there is no significant difference.

So exactly what is your point? That Ruby on Rails cannot possibly be as productive as the promonents might say? Or that no framework winds up surviving the initial hype?

There's a common perception that you can never achieve a 10X productivity boost over the state of the art. I don't believe that thinking at all. At some point, we stopped framing houses with hammers and started using nail guns. They were easily many times as productive. If you needed to build a very simple application requiring two phased commit and hard core object relational mapping with Ruby, you'd have to write all of the infrastructure yourself. Java could easily be many times as productive. And if you used Java plus servlets in the early years, you might well have achieved a multiple in productivity over C++.

Quite simply, Java is not an ideal applications langauge, and there are certainly languages that operate at a much higher level of abstraction. Ruby on Rails is what happens when you take one of those languages, challenge long-standing assumptions, and apply the result pragmatically to a problem space that is, quite frankly, lacking a good set of frameworks.

To me, the big surprise with Ruby on Rails is not productivity. In fact, there have long been more productive languages. Academics understand that functional languages are often more productive than Java, and Ericson has 20 years of research showing that functional languages and Erlang in particular are much better fits for distributed, concurrent programming. Seaside is rewriting the way we handle state with web applciations, and most programmers say it's many more times as productive as Java.

The thing that's happening here is this:

one of those languages is accumulating critical mass, as we speak. You've got marketshare and radical productivity in the same package. Re. management, surely you understand that other LAMP-oriented frameworks use a similar deployment philosophy? While the state of the art is nowhere near as advanced as the situation in Java, it is far better than you imply. With Capestrano, I actually find it easier to manage the depolyment of applications.

In fact, your implication that system management was born, or perfected, in Java is quite laughable. Many of the largest Internet sites have roots firmly planted in the LAMP camp. At my accounts, so far, we've found plenty of expertise in managing our deployments, and actually find Ruby's shared-nothing architectural philosophy easier to code, manintain, and scale than Java for certain applications.

I'm not saying that Ruby will replace Java. I'm saying that if you pick the right problems, you can expect radical productivity gains, and you should expect those gains to hold up reasonably well over time.

This article was a compilation of research across many companies that used these techniques to establish Ruby in Java shops. I'm under an obligation not to use the names of all of the companies, but some of them would definitely surprise you.

Your comments on the mythical man month deserve a separate post. Surely you understand that one of the common themes in MMM is that software projects break down exponentially with size. Bugs increase exponentially; communication costs escalate; projects bog down and die.

So, your answer to this phenomenon is what, keep investing in complex technologies that drive team sizes up? No. You should be looking for more leverage; not less. Ajax, services, and other demands are continually driving complexity up. At some point, we will have to raise the level of abstraction allowed by our programming languages, or suffer the consequences. New programming languages don't happen because we want better resume fodder. They come along because the old ones aren't up to the task anymore.

Will some apply Ruby to the wrong set of problems and fail? Absolutely. But that's another subject entirely.

Jon Tirsen's RPetStore wasn't enough of a thrashing for you Clinton? tsk tsk

21 hours from start to finish, including authoring the first working version of RBatis.

Yeah, and Microsoft claimed .NET was 5x more productive than Java too. It's all BS.

C# and Java are at a similar level of abstraction; Ruby is significantly higher.

There's a common perception that you can never achieve a 10X productivity boost over the state of the art. I don't believe that thinking at all. At some point, we stopped framing houses with hammers and started using nail guns. They were easily many times as productive.

To me, the big surprise with Ruby on Rails is not productivity. In fact, there have long been more productive languages. Academics understand that functional languages are often more productive than Java, and Ericson has 20 years of research showing that functional languages and Erlang in particular are much better fits for distributed, concurrent programming. Seaside is rewriting the way we handle state with web applciations, and most programmers say it's many more times as productive as Java.

The thing that's happening here is this:

one of those languages is accumulating critical mass, as we speak. You've got marketshare and radical productivity in the same package.

I'm not saying that Ruby will replace Java. I'm saying that if you pick the right problems, you can expect radical productivity gains, and you should expect those gains to hold up reasonably well over time.

Are you on crack Obie? ;-)

I know you're kidding, but so that people are not confused: It wasn't 2x - 5x. It was MAYBE 1.5 times -- and he had my implementation to work from.

Jon will admit that, and already did face-to-face with Roy at TWUSAD.

Don't tell tales.

Are you on crack Obie? ;-)

I know you're kidding, but so that people are not confused: It wasn't 2x - 5x. It was MAYBE 1.5 times -- and he had my implementation to work from.

Jon will admit that, and already did face-to-face with Roy at TWUSAD.

Don't tell tales.

Obie, unfortunately I have to disagree with you. Re-writting an app/framework is not a good measure for comparisons. However, I have to disagree with Clinton too :-]. Such a contest will proove nothing in the end.

The real problem here is, as I already said, the claims. I don't like claims without any near proof or that will never be able to have real proofs. And as Cedric is saying in another comment here:

What makes you think Ruby is so different from Erlang or Common Lisp, then?

Back in their time, they had the same hype, the same touted productivity benefits, the same group of rabid supporters. What is so different?

My point is that the language is just one of many things.

To whip out a web application that looks like crap and has a generated database that maps perfectly to CRUD forms...yeah, Ruby's better at that.

For an application with real-world databases and user interface requiremens...the language will be the least of my concerns. I'll build it with COBOL as fast as you would in Ruby.

Cheers,
Clinton

It's just not about higher levels of abstraction -- it *is* about the right levels of abstraction. The Rails APIs are so fluent, and feel so right for their intended usage, building database-backed web applications, that people have taken to calling Rails a DSL for web apps. The right level of abstraction makes teams more productive, which lets them be much smaller, which lets them communicate much better, which builds on the original productivity gains!!

My point is that the language is just one of many things.

To whip out a web application that looks like crap and has a generated database that maps perfectly to CRUD forms...yeah, Ruby's better at that.

For an application with real-world databases and user interface requiremens...the language will be the least of my concerns. I'll build it with COBOL as fast as you would in Ruby.

Cheers,
Clinton

My point is that the language is just one of many things.

To whip out a web application that looks like crap and has a generated database that maps perfectly to CRUD forms...yeah, Ruby's better at that.

C# and Java are at a similar level of abstraction; Ruby is significantly higher.

What about Groovy?
What about Grails?
Isn't Groovy close enough?

There's a common perception that you can never achieve a 10X productivity boost over the state of the art. I don't believe that thinking at all. At some point, we stopped framing houses with hammers and started using nail guns. They were easily many times as productive.

We're talking about software, here, not mass production. Please use analogies that make sense.

To me, the big surprise with Ruby on Rails is not productivity. In fact, there have long been more productive languages. Academics understand that functional languages are often more productive than Java, and Ericson has 20 years of research showing that functional languages and Erlang in particular are much better fits for distributed, concurrent programming. Seaside is rewriting the way we handle state with web applciations, and most programmers say it's many more times as productive as Java.

The thing that's happening here is this:

one of those languages is accumulating critical mass, as we speak. You've got marketshare and radical productivity in the same package.

What makes you think Ruby is so different from Erlang or Common Lisp, then?

Back in their time, they had the same hype, the same touted productivity benefits, the same group of rabid supporters. What is so different?

>> you could build x application with COBOL as fast as another
>> could build it in Ruby is telling.

My comparison of Ruby to COBOL is more relevant than your comparison of Ruby to C. Both COBOL and Ruby would make appropriate choices for an OLTP back-end for a web application. (Ajax + COBOL anyone?) ;-)

>> The "all programming languages are created equal" argument is bogus.
>> It's a false promise.

First, I didn't say that. Second, I agree with you. I think most operating system developers and device driver developers would agree that C is a much more productive language to work with than Java, Ruby or COBOL.

Cheers,
Clinton

The difference is critical mass. Count the downloads. (More than Spring or Hibernate.) Books on the framework. Commercial training courses. Check the slope of the adoption curve. Visionaries adopting it.

I don't think you have all of the Rails download numbers (you just have the gems), but you'll need to count Rails/Spring downloads over the same period of time. Like now, for instance. (the past quarter/month/this calendar year). I'm on the road, and don't have my spreadsheet with me, but the total numbers have been closing for quite some time.

Hi Bruce,

I've counted the downloads. The numbers I have show:

460,296 downloads for Rails (gems.rubyforge.org/stats.html)

and

854,879 downloads for Spring

(Spring 1.x - sourceforge.net/project/showfiles.php?group_id=...)
(Spring 2.x - sourceforge.net/project/showfiles.php?group_id=...)

(Feel free to start in mid 2004 when Rails started if you desire).

I don't really care about Hibernate. I don't mean to call you out, but I am curious where you get your numbers.

Keith

My point is that the language is just one of many things.

To whip out a web application that looks like crap and has a generated database that maps perfectly to CRUD forms...yeah, Ruby's better at that.

Ah. Now we're getting somewhere. What if you can improve the scaffold? Easy to do in Ruby. Much harder in Java. And that metaprogramming capability is at the core of the Ruby advantage.

What do you think of Maven 2 scaffolding feature? From my experience, it's quite powerful and allow me to generate sources very easily (archetypes, generate source phase, resource filtering, ...). There is already a Hibernate 3 plugin allowing me to generate a DB schema and java classes automatically from Hibernate mapping files. I don't like this approach but if it is what you want to do, it is quite easy to perform.

And what about Seam? Seems like a good answer from the Java side to RoR.

When you get back in the office can you post your spreadsheet here?

Can you also tell me where I can get stats for Rails downloads broken down for the last calendar year? I'll be happy to compare them to Spring stats for the same period and report my findings.

Here is a real stat for you: A Spring-based (Java) app has rolled into production replacing a legacy system that powered 5 billion debit/credit transactions worth 4.5 trillion Euro in 2005. The system provides national infrastructure for the entire United Kingdom--its operation is absolutely essential to the country's economy. They have never lost a transaction and they aren't about to start now, either. Performance has been benchmarked as being capable of scaling to 12,000 transactions per second. The introduction of Spring has been attributed to a 30% gain in developer productivity.

(Source, part 1 here: www.springone.com/display/SpringOne06/Podcasts)

I think it's going to be a while before we see Ruby scale to that level.

Furthermore, this system was exciting to build--why? Because the developers working on it were able to focus on solving the core business problems (like ensuring data integrity) and were *not* hampered by mundane framework issues along the way. The complexity was in the domain itself.

DHH recently made an arrogant comment calling "enterprise" developers "sorry people", or something to that effect. You know what, I take offense at that. These people are rolling out systems like the one above that make more money than all the trivial RoR todolists put together. How short sighted.

Keith
www.springframework.org

The writing is on the wall and Java is on the defense.
Even though Ruby and Rails is immature, infrastructure changes take a long time. And considering the Java community is a little disillusioned right now I think its fair for managers to start making a case for rails.

Does it fit the "silver bullet" model. Yes. And we know there are none. But mgmt expects churn and blames the technology frequently because they dont understand people or process. So even though we know better, Java is not forever and new directions arent necessarily bad.

If you are good Java programmer you will probably with a little study make a great ruby programmer. The reverse isnt necessarily true but whatever. Us Java guys could use a little instruction in smalltalk.

Who cares about SUN and Oracle and all those guys. they will take care of themselves. Java has done alot, and will be here forever, but I dont intend to be the curator of the new cobol either.

From whence it comes it comes. When ruby hits the point of inevitability I will be right there with it just like I was when Java hit the same point.

RoR to me is a textual 4GL. With the advantages and downsides that 4GLs have: build a standard CRUD application with default UI extremely quickly. Get stuck in huge problems if you want something different.

The difference is that RoR is a textual 4GL; a fact that together with it's open source nature, lends it street credibility and makes ideal for gurus: they are not dependent on a corporation but can hang out on mailing lists and fora.
Which is fine.

To me it's not only about languages but also about platforms; the availability of libraries and frameworks and ides etc. It took java 10 years to come to level that is really what you want. My heart bleeds for all the infrastructure code that will be written and debugged again. I really think the open-source community would gain if they would all run together on one VM and be able to make use of one another.
This will not happen of course. Sigh.

It is in the nature of gurus and developers when most of the problems have been solved and the market is mature, as is the case in Java, to move on to a new shiny bauble to start to solve the same problems again. Java did that to a large extent, and now ruby is doing the same.

Probably this is the nature of the circle of IT life. But it fails to excite me.

Its one thing to count the downloads but to me this only a weak indicator for success. You speak Ruby has reached critical mass? Yes and no. In the last 12 months i worked for major telco companies everyone knows and i have never seen a project there running on ruby. In fact i only saw a scripting based language in projects one or two times at all (and it was PHP and Perl) but these were more "playground projects".

People would calm down if they start realising that Ruby is in _no way_ a threat to Java but to PHP. My bet is that Ruby will never (and i really mean never) be adopted in highly transacational business systems. Most of the folks in the ruby camp i know are in fact not typical enterprise developers. No offense intended.

I think RoR is great for very specific projects where complexity is overseeable. If you wanna go for a small web based CRM system, it might be a good choice. Unfortunately, the systems i see in corporations are that complex (not because of J2EE but because of domain problems) that it is a no-go for ruby. Or do you want to write a Network Management System (like i do) that keeps track of a mobile carriers GSM network with millions of records per hour with ruby? I doubt that.

Only because of some people switched from Java to Ruby doesnt mean both langs play in the same league.

Marc Logemann
www.logemann.org

It would be interesting though if a RoR team would take part in a RAD Race as took place at Javapolis. 12 hours to build a given set of requirements. That time teams using Spring and Oracle ADF ao took part.

Joost, I have to say it again: this is gonna proove nothing. A contest is a contest, real life is always different. And this whole new discussion is about real life. We've seen a lot of claims, comparisons, etc. about Ruby vs Java, RoR vs Java webframework, etc. We both know that there are lots of Java projects built every day (and there will continue to be). Also, we both know that there are Ruby/RoR projects built and there will continue to be. Is Ruby gonna replace Java? Nope, as Java haven't replaced C++/C#. Is Ruby gonna replace Python/PHP? I really don't know (and I don't think so). It is a place for all of them. There are places where each of these are more fitted than the others. I perceive the rest of it as only guerilla marketting (pick the giant of the moment, kick it and see if people are looking at you).

./alex
--
.w( the_mindstorm )p.

Yeah, the takeaway I've gotten from seeing Bruce's posts is that:

- In the realm of small database driven web apps where Bruce has been consulting, webapps which were being built in Java but were probably better suited to PHP are now sometimes being built in RoR instead.

I say "probably" because either PHP or RoR are probably better than Java at these types of apps, but only if the app isn't going to grow to need integration with other systems or need to use legacy datasources which might not be the prettiest, etc.

Do downloads tell us a lot here? No, not really. Lots of people use PHP, but it hasn't really been a threat to Java in the past (or in the future). Scripting languages get used by a lot of people for a lot of projects, but they tend to be smaller quicker projects. There's probably a lot more PHP apps installed and running out there than there are Java apps, but the total dollar volume running across ALL of them probably doesn't add up to the one app Keith pointed out above.

The success of that UK project is worthy of praise and celebration. First of all, that sounds like exactly the sort of project where you need the maturity and performance of Java. Second of all, the team of Java programmers that put that system together is probably top-notch.

C# and Java are at a similar level of abstraction; Ruby is significantly higher.

C# and Java are at a similar level of abstraction; Ruby is significantly higher.

Bruce, I agree with you in principle that manyfold productivity gains are possible. However, I think there are some important questions:

At what point do higher abstractions on the language level become more important than abstractions on the library level? Java has hugely more libraries than Ruby at this time, so the likelyhood that I do not have to write code at all to solve a particular problem is much higher in Java than in Ruby. I don't think the possibility of using C based libraries counts, because of the issues outlined below and because less and less code is written in C/C++.

Does Ruby actually have higher level abstractions, or is it just a slightly different kind OO language? I think the meta programming facility is indeed a substantial difference in the abstraction level compared to Java (not as much as the difference between assembler and C though). However, whether it makes a significant productivity differnce in a particular project depends a lot on the type of code you need to write. The more algorithmic the code is, the less you gain by using metaprogramming. And yes I have seen quicksort implemented in Haskell, but that's really a trivial case compared to, say, data mining algorithms or some of the numerical stuff.

But where Ruby really falls down for me is speed and the way to work around the speed issues. Switching to C for algorithmic parts of the program kills productivity like nothing else. Using available C/C++ libraries in Ruby can be nasty because you need an adapter layer and you have to work around C++ compiler issues, platform dependencies, etc. I don't like that. In fact I hate it so much, that I would never even think of using Ruby for any project that might require speed, even if it was for just 1 % of the code. The Ruby on Java or .NET VM implementations do not seem to be well regarded within the Ruby community. Everything around VMs in Ruby (and indeed in the whole open source community) is quite fragmented and mired in ideologic warfare at the moment.

So my conclusion is, that for some important parts of many modern applications, Ruby's abstractions would indeed make programming more productive. My estimate is something around a factor 2 on average. BUT as long as the speed and platform independence issues are not resolved, that is as long as the main Ruby implementation is not based on a VM with a JIT, Ruby doesn't stand the slightest chance to become really widespread. All the "enterprise" things like TPC, legacy connectivity, etc will come along in spite of DHH's ignorance.

When you get back in the office can you post your spreadsheet here?

Here is a real stat for you: A Spring-based (Java) app has rolled into production replacing a legacy system that powered 5 billion debit/credit transactions worth 4.5 trillion Euro in 2005. The system provides national infrastructure for the entire United Kingdom--its operation is absolutely essential to the country's economy. They have never lost a transaction and they aren't about to start now, either. Performance has been benchmarked as being capable of scaling to 12,000 transactions per second. The introduction of Spring has been attributed to a 30% gain in developer productivity.