BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

InfoQ Article: From Java to Ruby...

by Obie Fernandez on Jul 27, 2006 |

The first article of a series from evangelist and accomplished author Bruce Tate presenting advice on how to convince your managers of the benefits of moving from Java to Ruby.

Ruby is an excellent language. If you want to establish it in a conservative company, implement a pilot progect using the language to solve the right problem in the right context. Let Ruby do the rest. But in order to establish your pilot project, you'll need to first build a case that makes Ruby attractive enough to take the risk. Then, you'll need to add some structure to your pilot strategy. With the resistance inherent in adopting a new language, you want to pick an approach that leaves no room for doubt. Finally, you'll want to lay the political groundwork for success.

Read From Java to Ruby: Strategies for Pilots.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Please god no.... by Steve Jones

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.

a few notes by Alex Popescu

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.


Still, other scripting languages have been around for longer time, with more live products. I think there is still some more to be prooved in this direction for Ruby.

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


What are the revolutionary features of RoR? Something, that cannot be found in let's say Java, Python, etc.? Something, that haven't existed in these before RoR?

I am not a flame starter. As I pointed out in many cases, I love Ruby (I am even active on Ruby ML). Also, as a core developer of a Java webframework (WebWork) I appreciate all good ideas in RoR. But, I still lack to see some arguments for some of the claims.

BR,

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

Re: a few notes by Clinton Begin

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.

Re: Please god no.... (from the author) by Bruce Tate

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.

The Mythical Man Month by Bruce Tate

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.

Re: a few notes by Obie Fernandez

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.

Re: a few notes by Bruce Tate

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


I disagree. You're basically saying that language x will never be more than 1.x times as productive as language y, and that's absurd. You can't generalize like that. C *was* much more productive than assembler; Java *was* much more productive than C++ for internet stuff, because C didn't have the libraries. Lisp will kill Java for writing parsers from scratch, or handling other highly symbolic tasks. Erlang will kill Java for large scale concurrent, distributed telecom switches.

When you're talking about a general purpose language like Java with lower level frameworks against integrated frameworks significantly more specialized, you *can* expect significant productivity improvements. Your claim that green-field, database-backed web apps are somehow imune is absurd.

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

My claim is that for greenfield database-backed web apps, especially those that require Ajax, Ruby on Rails *is* several multiples faster. And for the types of applications I've been writing, that's proven to be true.

Re: a few notes by Horia Muntean


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?

Re: Please god no.... (from the author) by Cedric Beust

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?


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.


Finally a reasonable claim. Of course, similar things can be said of Erlang and Common Lisp.

The truth is that at any time, there are always countless technologies "gaining critical mass". The problem is that hardly any ever reaches it.

--
Cedric

Re: a few notes by Clinton Begin

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.

Re: a few notes by Clinton Begin

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.

Re: a few notes by Alex Popescu

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?


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

Re: a few notes by Clinton Begin

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

Re: a few notes by Obie Fernandez

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!!

Re: a few notes by Bruce Tate

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


I've said many times that if Java isn't the problem, Ruby isn't the answer.If you're saying that technology is only a small part of the problem, I agree with you.

But languages can provide leverage. And at a certain point, leverage leads to other tipping points that come into play. You know that at thoughtworks, your peers have made increasingly aggressive productivity claims.

Are they all related to technology? Of course not. But if you can improve enough to hit certain tipping points, other things come into play, like team sizes, communications costs, and other multipliers. Ruby's leverage is very real. I've experienced it.

But your overall bias comes out in this statement: you could build x application with COBOL as fast as another could build it in Ruby is telling. The "all programming languages are created equal" argument is bogus. It's a false promise.

Re: a few notes by Bruce Tate

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.

Re: a few notes by Bruce Tate


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?


Perhaps. I don't think we know yet. But Rails is so interesting because it's the first time we've see one of the higher level dynamic object oriented languages with a catalyst. It's Lisp, or Smalltalk, with marketshare. And that's compelling.

Re: Please god no.... (from the author) by Bruce Tate

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.


OK. C and assembler.



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?

This is my point exactly. Ruby on Rails is different because you have a higher level language, with a catalyst, that is crossing the chasm.

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.

For the first time, we have Lisp, or Smalltalk, with marketshare.

Re: a few notes by Clinton Begin

>> 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

Re: Please god no.... (from the author) by Keith Donald


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.


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

Re: a few notes by Alexandre Poitras

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.

Re: Please god no.... (from the author) by Bruce Tate

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

Re: a few notes by Bruce Tate

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.


All steps in the right direction.

Ruby vs. Java (Spring) Momentum by Keith Donald

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

its not too early by Bill Culp

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.

solving the same problems again & again by Joost de Vries

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.

stop counting downloads, check the real world by Marc Logemann

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

Re: solving the same problems again & again by Joost de Vries

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.

Re: solving the same problems again & again by Alex Popescu

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.

Re: stop counting downloads, check the real world by Jason Carreira

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.

Re: Ruby vs. Java (Spring) Momentum by Obie Fernandez

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.

Re: a few notes by Paul Hammant


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


Slightly related: I'm reminded of the definitions of 1GL, 2GL, 3GL and 4GL. Ruby is a 3GL right?

Re: a few notes by Paul Hammant


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


Slightly related: I'm reminded of the definitions of 1GL, 2GL, 3GL and 4GL. Ruby is a 3GL right?

Re: a few notes by Faui Gerzigerk

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.

Re: Ruby vs. Java (Spring) Momentum by Bruce Tate

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


I'm back, but the spreadsheet is not where I thought it was. That means I need to go back to my incremental backups, and I'm not willing to do that right now. But even a casual glance at your numbers (without all Rails delivery platforms) should tell you that Rails covered the same ground much more quickly than Spring did. Rails was sitting at 60K gem downloads this September, so over 85% of the growth has been in the last ten months. That's only important because I consider Spring a successful project with significant marketshare, and it makes an interesting backdrop for those who would claim that Rails marketshare is insignificant.


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.


Congratulations. I think anyone would be crazy to try that project today in Rails. I've never said differently, and From Java to Ruby certainly says to do projects like that in Java. Just this past weekend, I taught a Spring session, and pointed two developers to Spring over Ruby ()the biggest argument was for Web Flow) because Spring was a better technical fits. I've said twice on expert panels this year that I think EJB is effectively dead, that Spring killed it, and that Spring is now the best way to build enterprise applications.

Most of the people claiming "one size fits all" are firmly in the Java camp. I think Rails is best-suited for small to medium green-field database-backed web apps, and have never said differently. I tend to believe that's the most important niche...it certainly forms the lion's share of my client base, and understandably has since Better, Faster, Lighter Java won the jolt.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

35 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT