BT

From Java to Ruby: Strategies for Pilots

Posted by Bruce Tate on Jul 27, 2006 |

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. The Rails community now contributes an extensive list of plugins (called Gems), books (10 Rails books this year), training, a major conference, and an impressive library of online resources. As Rails makes a splash, even the most conservative companies will begin to consider Ruby.

But so far, this is a revolution has been led by developers. Convincing management takes another kind of persuasion. A manager needs to understand the risks of adopting Ruby, the risks of snubbing mainstream languages like Java--even for one project--and the overall technical landscape of Ruby's capabilities. Frankly, current literature comes up short in this area. This article series, based on From Java to Ruby, will explore the adoption of Ruby in conservative accounts in three areas: pilot projects, understanding risks, and Java/Ruby integration strategies.

The Pilot approach

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.

So your first step should be establishing a reward, and one compelling enough to overcome the risk of adopting a new language. With Ruby, building your case is easier than you might think.

Finding a compelling reward

When all is said and done, your core advantages will likely revolve around short and long term productivity. Short term productivity deals with the immediate development of your application. Longer term productivity includes the overall maintenance and simplicity of an application. Like most scripting languages, Ruby excels at short term productivity. 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.

Ruby, and the flagship Rails framework, leads to dramatic productivity improvements, often approaching a factor of three to five for certain applications. When you drive your productivity up, you can drive team sizes down, reduce communication costs, and eliminate overhead. Smaller teams can also improve the effectiveness of agile development processes. The multiplicative impact of these kinds of improvements is often understated.

Developers understand the impact of dynamic typing, metaprogramming, domain specific languages, and richer abstractions such as closures and continuations. The Ruby on Rails framework has still more revolutionary features that have not yet been duplicated in Java frameworks. The rapid feedback cycle, baked-in testing, convention over configuration and revolutionary persistence framework are all attractive to Java developers. But you can't rattle off a feature set and expect the impact of your arguments to stick when you're talking to middle management. You need to express those features in terms of productivity.

Longer term benefits exist as well. Reduced configuration, striking simplicity, fewer lines of code, and domain-specific languages typically make Rails applications easier to read. Baked-in testing frameworks simplify unit, functional, and integration tests. The dynamic nature of Ruby makes Rails applications easier to extend. Taken together, these attributes all lend themselves to easier long term maintenance and extension.

Real resistance

A typical manager sees new technologies as huge, neon risk signs, and for good reason. New technologies are inherently risky, and new programming languages take risks to a whole new level, because that decision will last for the lifetime of your application. These troubling risks are persuasive:

  • You could pick the wrong problem.
  • The language could stagnate, limiting support and enhancements in the future.
  • The language could fail to deliver technically.
  • The language could lead to long-term problems that are not yet clear.
  • You could fail to understand the new technology.

When it all comes down to making the switch from Java to Ruby, you need to reach beyond technical arguments to convince a technical decision maker that Ruby can provide enough business value to overcome the inherent risk of adopting a new language. Your potential reward must overshadow the risk, and your pilot must prove your benefit without a doubt.

Your Pilot Strategy

For From Java to Ruby, I interviewed dozens of developers who have built, or are building production applications in Ruby. I explored pilot strategies that worked to establish Ruby in all different kinds of companies. The goals of a pilot are usually twofold:

  • The technical risk axis. Problems with high technical risk help you learn more about the technology you're exploring.
  • The political risk axis. You want skeptics to see the technology succeed so you can use it.

Often, these goals are at odds. Selling usually demands less technical risk because you can't sell failure, but higher political risk for visibility. Learning requires slightly more technical risk, because you won't learn a thing by building one more to-do list or blog. And the higher technical risk usually will be in the context of lower political risk.

The first step in planning any successful pilot is planning an effective strategy that balances these goals, and takes advantage of your resources at hand. These strategies come directly from the book. I learned each from a Ruby developer who applied the technique to deliver a working production application.

Trojan Horse

Many technologists try to make a big splash with Ruby, only to get frustrated by politics and risk-averse philosophies. After a few setbacks, they quit. The Trojan Horse tends to work well at companies that move into new technologies very slowly. With this strategy, you work to move Ruby into the system beneath the radar. Here's the general idea:

  • You find an unexciting technical problem.
  • You quietly solve the problem with Ruby, with as little management visibility as possible.
  • You establish a grass-roots campaign to build Ruby evangelists by nurturing culture.

The Trojan horse has low technical risk, and also low political risk. Your goal is to establish some early success with simple problems, build up technical advocates through internal evangelism, and increase in technical and political scope as you accumulate more clout.

Amazon.com is a good example of a company in the early stages of establishing Ruby through the Trojan Horse technique. Steve Yegge, who worked at Amazon.com but is now at Google, is a programming language aficionado who began using Ruby a few years ago. With a number of others, he made sure Ruby was available to developers. Some Ruby visionaries including Dave Thomas (the author and publisher of the most popular Ruby books) and David Heinemeier Hannson (the creator of Rails) have each spoken at Amazon.com, though Ruby is only used there as a scripting language. But the community is growing, and use is expanding.

I was at another company who had an excellent opportunity to implement a Trojan Horse scenario. A European consultancy worked on a Java project, and ran out of money before they were able to build an administration console. Instead of building a console, the customer is managing the database with direct SQL, and is at considerable risk of data integrity problems. We decided that the console would have been trivial to build in Ruby on Rails, but quite demanding for Java. I never found out whether this customer moved forward with Rails.

Objections

With the Trojan Horse scenario, your goal is to eliminate objections by going unnoticed. If you do encounter objections, you'll try to position Ruby as a utility scripting language in the same spirit as Perl, HTML, SQL or XML.

When all is said and done, the Trojan Horse is purely a grass-roots play. You seek to patiently build fertile soil for your grass to grow. By establishing success in small increments, you bet that you'll be able to grow a Ruby project, or the role of Ruby in the enterprise. You will often choose not to go through a formal approval process, or work around such a process based on the low importance of the problem you're solving.

The Race

By far the most interesting scenarios I encountered was the Race scenario. The premise is this:

  • You take a demanding problem that's already being solved with Java.
  • You spend your contingency budget on building a Ruby project in parallel.
  • You build a team that has roughly 20% to 33% of the number of developers on the Java project.
  • After a period of time, you pick the project that's farthest along.

With this scenario, the technical risk for the Ruby project is high, but you hope to offset that risk by having a Java project in parallel. The Race scenario makes a very strong case for the productivity of Ruby. The downside is the cost of failure. If you fail, you wind up funding two development efforts for a period of time. But if you succeed, you'll wind up spending much less in the long run. In a real sense, the Ruby project becomes a high-risk focal point with a very high potential payoff, and the parallel Java project becomes expensive insurance. If Here are some of the ways I've heard the race scenario pitched:

  • One consultancy built a Ruby project in parallel with a Java project, funding the development effort themselves. They viewed Ruby as strategic, and hoped to use the Race scenario to convince the customer that Ruby on Rails was a viable alternative.
  • One developer offered to spend one day developing in Ruby and four days in Java. The manager could choose the best solution after a month or so.
  • One consultancy built prototypes in both Java and Ruby to demonstrate the effectiveness of the Ruby solution.

This strategy is a little jarring, but quite useful for convincing managers who are intrigued, but unwilling to pull the trigger. The Race scenario showcases the explosive productivity of Ruby like no other. Out of four race scenarios I encountered, two succeeded, a third is not yet complete, and the fourth project was under budget and ahead of schedule, but lost funding.

The Race scenario is actually less radical than you might expect, especially if the management team has an idea that Ruby is possibly many times as productive. Though the expense is high, this scenario is among the least risky Ruby scenarios. Be careful, though. One of the downsides is that Java remains an option even after your pilot is underway, even if you are successful. You can succeed technically, but still fail to make your case politically. One customer I interviewed completed a successful Ruby pilot, coming in at 1/4 of the cost of the Java projections. The customer loved the "prototype" and asked for it to be completed in Java.

Objections

With the Race scenario, the biggest objection will be cost. Your response to this objection should be unemotional and well reasoned. If you are successful, your overall costs may well be less than a completed Java project. Consider a project where Ruby is four times as productive, such as a classic Rails application. If management decides to ride Rails and scrap the Java side of your project half way through, your total costs would be only 75% of the cost of building the Java project from scratch. If you pulled the trigger on Ruby 25% of the way through the project, the total project would cost only 50% of a total Java effort based on finishing the project with a more productive technology. Surprisingly, your break-even point is at 75% of the way through the project!

The two pilot projects I show here are just two of the approaches I've seen. You can take many other approaches:

  • Implement a classic pilot, emphasizing learning over selling.
  • Rescue a failing Java project by using small teams with Ruby.
  • Put out a low bid for a Java project, betting that you can succeed with less total effort. I've successfully submitted a fixed bid projects for 30% off of the best fixed Java bid, for example.
  • Showcase a flagship framework capability such as domain-specific languages or Ajax integration.

Certainly, other effective techniques exist. In some companies, such as those with strong Ruby advocates, Ruby will be a relatively easy sell. In those cases, the role of a pilot changes. You'll want to emphasize learning over selling. In every case, you'll need to keep working to keep the ball rolling.

Capitalizing on success

The absolute key to leveraging a successful pilot to advance your agenda is data. You will want to collect honest, accurate metrics describing your success. You'll usually want to emphasize productivity, but you'll also want to show practical data in areas where there may be major objections:

  • Performance data. A common Ruby objection is lack of scalability. This objection is not usually grounded in reality.
  • Ramp up. Most managers expect to ramp up Java developers faster than Ruby counterparts, based on the available pool of talent. Rails ramp up is actually very fast.
  • Team size. This argument is usually quite compelling. You can do more with less.
  • Lines of code. Count total lines, but don't ignore lines of configuration.

This extra effort doesn't take much time, but will make it much easier to capitalize on success. As you work to establish Ruby in a Java environment, keep in mind that you're going to have to show striking improvement. The key is to balance your technical and political goals. You need to decide what will work in your political environment, and how much technical ability your team can deliver. If you want to effectively sell Ruby against Java, use a Ruby pilot to solve the right problem in the right environment. Let the language speak for itself.

About the author

Bruce Tate, founder of RapidRed, LLC is a kayaker, mountain biker, father, author, and Java programmer in Austin, Texas. His five books include "Better, Faster, Lighter Java" and best-selling "Bitter Java". His 17 years of experience include stints at IBM, two failed startups, and his own independent consulting practice called J2Life, LLC.

Hello stranger!

You need to Register an InfoQ account or 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-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT