BT

InfoQ Article: From Java to Ruby - Risk

by Floyd Marinescu on Aug 31, 2006 |
"Ruby is risky" is a common perception. As Ruby on Rails moves closer to the mainstream, that risk will decrease. In this InfoQ article, Bruce Tate examines the changing risk profiles for Java and Ruby from a managers perspective, examining Java's initial adoption and comparing it to risks for Ruby.  Bruce looks at real risks with Ruby that he has experienced, and then also debunks a number of common risk myths about Rails.

Read From Java to Ruby: Risk.

Some of the common myths Bruce examines:
  • Rails is a silver bullet.
  • Choosing Ruby is too risky, because you could guess wrong.
  • It's always easier to staff a Java project.
  • Rails cannot scale
  • Rails integration options are too limited.
So Ruby's risks are often overstated when you consider the whole picture, especially if Java is not giving you everything you need. The best way to put these risks into perspective is often to try Ruby for yourself. Use Rails to build something nontrivial, and make a call based on what you find. Don't buy into the myths.
See also the first article in this series: From Java to Ruby: Strategies for Pilots.

Editors note: This article has not been tagged for the Java community because Java developers interested in Ruby would have left the Ruby community turned on and would thus be able to see this article.  We assume that those who turned Ruby off don't want to hear about Ruby,  so we respect their personalization preferences.

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

Correction of the posted article by Baron Davis

My apologies for the readers, but the title of the article was mispelled. It should say :

"How you, script kiddies, can play with building simple tiny CRUD web apps, and enjoying your ignorant life without clustering, legacy system integration, distributed caching, [put your favourite here]..."

It is quite amazing to see article after article that has the same error, but no correction from the original posters whatsoever.

Peace

Re: Correction of the posted article by Alex Popescu

The author clearly speaks about niche-markets. Also, we must agree that not all built apps are needing clustering, legacy system integration, etc. Now, I am wondering what is wrong with having different tools to build different solutions?

./alex
--
:Architect of InfoQ.com:
.w( the_mindstorm )p.

Re: Correction of the posted article by Floyd Marinescu

Baron - the article did not attempt to pitch Rails as a solution for large scale distributed systems so it's not fair to criticize it as though it was. It's a fact that Rails is optimal for green field web apps, as evidenced by the Java community attempting to emulate many of these features on it's own web frameworks.

If you're not interested in Ruby/Rails content then you feel free to turn the Ruby community off (see that little widget on the left side bar).

Floyd

Re: Correction of the posted article by Alexey Verkhovsky

There are ways to do clustering, legacy system integration and distributed caching with Ruby. And calling Bruce Tate a script kiddy is, well, misguided.

Re: Correction of the posted article by Baron Davis

Also, we must agree that not all built apps are needing clustering, legacy system integration, etc.

I agree 100% with you.

Now, I am wondering what is wrong with having different tools to build different solutions?

Actually I am really interested in Ruby and other technologies because they all reflect the direction in which software evolves, however it is quite annoying to regulary see comparison of RoR and Java, where
usually Java is mentioned in negative context.
I like to read articles of type: "RoR helps you solve the X problem", but dislike regular badmouthing of type "RoR vs entire Java environment".

It's a fact that Rails is optimal for green field web apps...

IMHO, than this should be stated clearly in the article. Otherwise you are deceiving public (where public in this case are young minds of young unexperienced developers who are still unable to create their own opinion on this subject).

If you're not interested in Ruby/Rails content then you feel free to turn the Ruby community off

As I said previously, I like to read news about Ruby/Rails, but dislike this type of articles, so it seems I am in no win situation.

Nothing personal guys, site is great, but considering that you are in this powerful position where you can affect direction, either good or bad, in which young creative developers will develop their skills, I felt obliged to speak out.

Peace

Re: Correction of the posted article by Baron Davis

Also, we must agree that not all built apps are needing clustering, legacy system integration, etc.

I agree 100% with you.

Now, I am wondering what is wrong with having different tools to build different solutions?

Actually I am really interested in Ruby and other technologies because they all reflect the direction in which software evolves, however it is quite annoying to regulary see comparison of RoR and Java, where
usually Java is mentioned in negative context.
I like to read articles of type: "RoR helps you solve the X problem", but dislike regular badmouthing of type "RoR vs entire Java environment".

It's a fact that Rails is optimal for green field web apps...

IMHO, than this should be stated clearly in the article. Otherwise you are deceiving public (where public in this case are young minds of young unexperienced developers who are still unable to create their own opinion on this subject).

If you're not interested in Ruby/Rails content then you feel free to turn the Ruby community off

As I said previously, I like to read news about Ruby/Rails, but dislike this type of articles, so it seems I am in no win situation.

Nothing personal guys, site is great, but considering that you are in this powerful position where you can affect direction, either good or bad, in which young creative developers will develop their skills, I felt obliged to speak out.

Peace

Re: Correction of the posted article by Alexey Verkhovsky


It's a fact that Rails is optimal for green field web apps...
IMHO, than this should be stated clearly in the article.


Perhaps, you underestimate what can be done with Ruby. The article, on the other hand, seems to state those limitations rather clearly.

Greenfield web apps are where the advantage is most noticeable, but I know people who built a Rails frontend to a legacy Oracle database designed by committee. Reportedly, hey saw productivity gains even in that project.

Re: Correction of the posted article by Alex Popescu

[...]however it is quite annoying to regulary see comparison of RoR and Java, where
usually Java is mentioned in negative context.


Well, I guess most of us Java developers feel quite the same. But, it is a well known marketting strategy to kick the giant of the moment in order to gain more attention. The good news is - and this is only my opinion - that Ruby is one of those things deserving attention.

./alex
--
:Architect of InfoQ.com:
.w( the_mindstorm )p.

Re: Correction of the posted article by Stefan Tilkov

Baron, it seems to me that your points are valid for many articles -- although hopefully for none of those published on InfoQ. No offense, but did you actually read this particular one? It does not seem to suffer from the script-kiddy-silver-bullet symptom IMO. But maybe I've missed the parts you allude to -- in this case, please point them out.

A language without a VM is sooooo 80s by Faui Gerzigerk

I think Bruce is right to focus on productivity as the factor that makes you want to cross the chasm. But where is that productivity if you have to drop back to C for anything more complex than CRUD? CRUD is not that first niche from which a language can go on to conquer the world. It's one of the few things a language 10 times slower than Java or C++ can ever do because CRUD means delegating all the real work to the DBMS and the operating system.

And no, it's not simply a matter of moving your work to JRuby or some CLR based Ruby implementation. Its creators started Ruby at a time when there were no mainstream VMs and they didn't create one either. And that means that Ruby (and Python and Perl) is stuck on that antiquated platform that is C. The implementors of JRuby have to port all the C based stuff to Java and they will always lag behind. It's a brain dead duplication of effort. More and more libraries are created for C based Ruby and there's no way anyone can keep up with porting that stuff to the JVM. C based Ruby becomes more entrenched every day and that means everyone doing anything other than CRUD has code it in C as well.

Are we really moving our infrastructures back to C just because we want to use some dynamically typed scripting language for the CRUD part? I don't think so. It's not that Ruby is too risky. It's that the Ruby environment as a whole is unproductive because it is based on an antiquated platform model.

Yes it's true, J2EE is unwieldy and bloated. Its development and deployment model runs counter to anything remotely agile and the latter hasn't changed in JEE 5 either. But does that mean we should roll back the real progress that has been achieved with JIT accelerated platform independent virtual machines? I think not. It would be a step back in time.

Joel on Ruby by J Aaron Farr

Funny, today Joel commented on a related subject:

"... and a handful of platforms where The Jury Is Not In, So Why Take The Risk When Your Job Is On The Line? (Ruby on Rails). Before you flame me, Ruby is a beautiful language and I'm sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I'm sure you'll have a lot of fun, but for Serious Business Stuff you really must recognize that there just isn't a lot of experience in the world building big mission critical web systems in Ruby on Rails, and I'm really not sure that you won't hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot..."

www.joelonsoftware.com/items/2006/09/01.html

Wow, Bruce is still going after Java by Marc Stock

He's being more sly about it now but I can't believe that people are still seriously comparing Ruby to Java. People who wanted to whip out quick web apps have always had the option of using languages like PHP and Python. How often do you see posts of this nature regarding Python vs. Java? Almost never.

ruby risk by Rusty Wright

I agree that Bruce glosses over with a very wide brush the advantages of Java, and likewise glosses over the disadvantages of Ruby. I happen to think that Rails is a great framework; for me it's Ruby that's the problem. I can't stop thinking that a language that uses run time type checking is simply less safe than one that uses complile time type checking. Regardless of whether it's a small team or even just one person, versus a large team working on a large project.

Re: ruby risk by Doctor Gonzo

Re: ruby risk by Bruce Tate

It's a risk/reward equation, no? Before automated testing, Java wins. Since automated testing, the reward for static typing is not so great.

I agree that Bruce glosses over with a very wide brush the advantages of Java, and likewise glosses over the disadvantages of Ruby. I happen to think that Rails is a great framework; for me it's Ruby that's the problem. I can't stop thinking that a language that uses run time type checking is simply less safe than one that uses complile time type checking. Regardless of whether it's a small team or even just one person, versus a large team working on a large project.


Ah...that's a pretty broad brush you're using. One size fits all. So...do you use

- Spring to delay binding until run time
- XML to configure anything, which also allows runtime type checking
- Byte code enhancement and reflection frameworks that use run time type checking, within the context of persistence frameworks?

So you use delayed binding and run time checking all of the time. You just don't get all of the benefits of a language that makes it easy to do the same.

Ruby is not for everyone. I never said it was. But this size definitely fits the apps I've been building lately...like a glove.

RoR is not JUST for greenfield apps by Steven Talcott Smith

I just completed a total rewrite of a LAMP system in RoR. I re-created a year and a half worth of part time development in a little under 3 months of part time Ruby. (Although the last few weeks going into production were full time.) As part of the re-write, I developed a lot of new features and COMPLETELY REFACTORED MY DATABASE MODEL -- with over 75 tables.

I have never in my entire 15 year career contemplated completely redesigning the database of a running, production application. Add a table here and there but never, ever perform major surgery. This was only possible due to a feature of Rails: Migrations. I am sure there are good tools out there to version your data model but I have come across nothing so sweetly integrated with your code base as migrations. I am one of those "Technologist/Early Adopters." Call me crazy now but I jumped on Java in '96. This is all that and more. And it's just plain fun.

I knew nothing about Ruby before starting and I never wrote a demo or greenfield application on it. I figured it would be more instructive to take an application that I actually understood and re-do it. Your milage may vary.

If you are a big self starter and your productivity is truely important (ie. your time is highly valued) -- consider RoR. If you tend to require formal training, you probably should wait till it is more widely adopted.

I have a nose for things and I suspect there will be good money in RoR consulting for the early birds...

Re: ruby risk by Bill de hÓra

" I can't stop thinking that a language that uses run time type checking is simply less safe than one that uses complile time type checking. "

Not really. The problem is comprehensibility, especially when it comes to mixins. It'll be interesting to see how Rails manages interface creep over the next few years. Systems that allow unfettered interface and function binding can be very hard to understand and work with in the whole (cf Zope 2). In java mucking about with classes and interfaces is limited to framework infrastructure. In Rails this is very much exposed to the app developer. That's touted as an advantage today, but it's not free. I expect Bitter Ruby will have a chapter called 100 Method Object.

Re: ruby risk by Rusty Wright

It's a risk/reward equation, no? Before automated testing, Java wins. Since automated testing, the reward for static typing is not so great.

This assumes that your testing exercises every line of your code and tests all possible permutations of its behaviour. I would guess that that's not very likely.

Ah...that's a pretty broad brush you're using. One size fits all.

So are you saying that having a tool that checks and verifies the type correctness of your code is something that only some people need or want? I'm not talking about any specific language here. Simply that it's safer to have something verify the code's correctness with respect to types.

So...do you use

- Spring to delay binding until run time
- XML to configure anything, which also allows runtime type checking
- Byte code enhancement and reflection frameworks that use run time type checking, within the context of persistence frameworks?

So you use delayed binding and run time checking all of the time. You just don't get all of the benefits of a language that makes it easy to do the same.

You're portraying it as Java vs. Ruby. For me it's the broader question of having something do type checking before I run the program. I want more type checking, and stricter type checking. I'm not saying that Java is the best language; something like Nice (nice.sourceforge.net/) would be better. I want as much help as possible from my tools to find potential and real errors in my programs before I run them.

Re: ruby risk by Rusty Wright

The problem is comprehensibility, especially when it comes to mixins. ... Systems that allow unfettered interface and function binding can be very hard to understand and work with in the whole (cf Zope 2). ... In Rails this is very much exposed to the app developer. That's touted as an advantage today, but it's not free. I expect Bitter Ruby will have a chapter called 100 Method Object.

opal.cabochon.com/~stevey/blog-rants/digging-in...

Re: ruby risk by Bruce Tate

I completely see where you're coming from. I don't think that Rails is perfect. In some ways, it's too accessable. The problem is that we're seeking the same sorts of Rails-like capabilities with Java right now. The complexity comes in a different form, but it still comes. You talk about the 100 method object; what about the 100-class framework to do the same?

Face it: Spring, AOP, heavy reflection, annotations, byte code enhancement, servlets, deployment descriptors, xml configuration...all of these delayed binding programming techniques come with intellectual baggage of their own.

The question is whether you want to be direct about it, at a limited cost, or indirect, at a far greater cost.

The problem is comprehensibility, especially when it comes to mixins. ... Systems that allow unfettered interface and function binding can be very hard to understand and work with in the whole (cf Zope 2).

There are better technologies the Ruby on Rails by Ulrich Weber

Sorry for Bruce Tate but the future of webtechnology (for us Java-developers!) might not be Ruby on Rails. The future might be GWT, Google's webtoolkit.

RoR is a pur serverside-framework whereas GWT is a complete client-side and server-agnostic webframework that helps us to build rich web-content in future. Does RoR help us to build rich content say Ajax-RIA's ? I don't think that a pur serverside-framework can provide those facilities. GWT does.

Furthermore RJS (Ruby-Javascript-templates) cannot provdide what GWT can. Being a clientside webframework and being server-agnostic is a very important point too: you can easily connect all kinds of so-called legacy applications like Struts to a GWT-frontend. Being server-agnostic allows us to use existing PHP-, Perl-, Python- etc. infrastructures such as Wikis, CRM's, forums etc.

Re: ruby risk by Alexandre Poitras

Great post. Couldn't have said it better.

Re: Wow, Bruce is still going after Java by Robert Dean

He's being more sly about it now but I can't believe that people are still seriously comparing Ruby to Java. People who wanted to whip out quick web apps have always had the option of using languages like PHP and Python. How often do you see posts of this nature regarding Python vs. Java? Almost never.


You took the words out of my mouth. The thing that really turns me off is that Java is singled out for comparison when the usual methodology is to make broad comparisons (to the broad spectrum of general-purpose web platforms: not only Java, but .net, Python, PHP, perl, ColdFusion, and others as well). This sort of Burger King/Pepsi (cut down the "market leader" but not the others) type of marketing works for some people, but not all.

The McDonald's/Coke type of marketing (brand awareness) would work better for Ruby. It's certainly worthy of attention and doesn't need to expend entire books to comparing itself to Java.

Re: Wow, Bruce is still going after Java by Rusty Wright

The thing that really turns me off is that Java is singled out for comparison when the usual methodology is to make broad comparisons ... This sort of Burger King/Pepsi (cut down the "market leader" but not the others) type of marketing works for some people, but not all.
I think it's an aspect of the strength of Bruce's feelings about these things. Previously he was evangelizing Spring and Java, now it's Ruby and RoR.

Software Needs Philosophers (not religious fanatics).

Re: A language without a VM is sooooo 80s by Charles Nutter

I beg to differ! In fact, we only had to port a few core libraries like YAML support, ZLib, and Sockets to get Rails running under JRuby. In 95% of cases, Ruby libraries are written in pure Ruby. In the few cases where a port is necessary, it's almost always just a matter of wrapping existing functionality in Java. For example, Java has very good ZLib and Socket support, so we mostly just had to wrap those existing features.

JRuby already can run Rails in many scenarios, and we're improving compatibility and performance day by day. Almost all C-based extension writers we've talked to are also very interested in having Java-based versions of their code. A notable supporter is Zed Shaw, creator of Mongrel, who has been very helpful in our efforts to bring Mongrel over to JRuby. Not only will JRuby be able to keep up...we'll be able to innovate in many cases. That means more Ruby for everyone!

Re: Correction of the posted article by Oyku Gencay

Baron,
Your attitude can easily be classified by reading this very article. You either should have read before posting or articulate the points.

Re: RoR is not JUST for greenfield apps by Cedric Beust

I just completed a total rewrite of a LAMP system in RoR. I re-created a year and a half worth of part time development in a little under 3 months of part time Ruby.

Assume you spent 18 months on a RoR project and you decide to rewrite it in Java, don't you think you will do so in much less time than 18 months?

--
Cedric

Re: ruby risk by Cedric Beust

It's a risk/reward equation, no? Before automated testing, Java wins. Since automated testing, the reward for static typing is not so great.

There is a big difference: the compiler forces you to obey static typing. There is nothing that forces you to test your code.

Which is exactly why applications written with dynamically typed languages are more fragile than those written with statically typed languages.

If you can put together a group of superstar programmers, there is no doubt they will do an outstanding job in Ruby on Rails. Or Ruby. Or Java. Or any language, for that matter. That's why they are superstars.

When your team is made of regular programmers, dynamically typed languages are much more of a liability than something like Java.

--
Cedric

Re: ruby risk by Ian Nelson

Do you have any evidence or can you point to any studies that show testing closing the reliability gap with weakly typed systems vs strongly typed ones? It sounds kind of reasonable but there is a ton of evidence, pretty much as long as software engineering has been around that shows a substantial advantage to having compile time checks.


Automated testing is not a terribly new concept, it is also something that has been going on since the 60's or even earlier.

Re: Wow, Bruce is still going after Java by Alexey Verkhovsky

[Ruby is] certainly worthy of attention and doesn't need to expend entire books to comparing itself to Java.


Being a disruptive technology, Ruby does need that, too.

There are people making decisions along the lines of "we are a Java shop now, is it a good idea for us to go Ruby today?". The answer may be "yes", "not today", or "not ever".

As a developer, I want to do Ruby work. As an IT consultant, I don't want to push Ruby where it's not a good choice. And in my world it's practically always Ruby vs. Java vs. C#. So, what Bruce is writing about is quite relevant.

Re: RoR is not JUST for greenfield apps by Steven Talcott Smith

I just completed a total rewrite of a LAMP system in RoR. I re-created a year and a half worth of part time development in a little under 3 months of part time Ruby.

Assume you spent 18 months on a RoR project and you decide to rewrite it in Java, don't you think you will do so in much less time than 18 months?

--
Cedric

Perhaps. A rewrite between comparable languages should take less time because you are not learning the domain model at the same time. However, I shudder to think about the task of rewriting 18 months of RoR in Java. From my brief brush with Python, I would say a rewrite in Python would be easier to contemplate.

The lines of code multiple with respect to Java alone would be enough to intimidate me out of that particular path. I prefer to work at as high a level as possible.

It is rare that one gets the opportunity to completely rewrite anything. If I were not also the head of the company, I would probably not have had the go-ahead. Even so, with my businessman hat on, I had my doubts, at least until I got into production.

Steven

Re: RoR is not JUST for greenfield apps by Cedric Beust


Perhaps. A rewrite between comparable languages should take less time because you are not learning the domain model at the same time. However, I shudder to think about the task of rewriting 18 months of RoR in Java.

A lot of this time might have been dedicated to refactoring and getting the model right, so you're definitely not looking at 18 months of new code, which is why the testimonies claiming that they rewrote an application with language X or framework Y in ten times less time are so preposterous.


From my brief brush with Python, I would say a rewrite in Python would be easier to contemplate.

Probably, yes.


The lines of code multiple with respect to Java alone would be enough to intimidate me out of that particular path. I prefer to work at as high a level as possible.

So do I, but just because it takes more lines of code to do Web applications in Java than in Ruby doesn't mean that it takes more time to do so.

--
Cedric
testng.org

Re: RoR is not JUST for greenfield apps by karan malhi


So do I, but just because it takes more lines of code to do Web applications in Java than in Ruby doesn't mean that it takes more time to do so.


+1

Re: Wow, Bruce is still going after Java by Robert Dean

And in my world it's practically always Ruby vs. Java vs. C#.


Yes, but the books are Ruby vs. Java. Where's the C# or PHP comparison? That is the core of my point.

My 2 cents on Ruby vs C# and PHP. by Alexey Verkhovsky

Re C#, as the article says "I'd throw C# into the mix as effectively a Java clone, though there's room for some argument."

That's my humble (but well informed) opinion as well. There are differences between C# and Java, but for the purpose of comparing them both to Ruby, those differences are not significant enough.

I know just enough PHP to say that the leap from PHP to Ruby is not that big. You are still on the LAMP stack with dynamic typing and interpreted code. In this genre, Ruby is an obviously better general-purpose programming language than PHP, and (from what I hear) Rails is an obviously better MVC framework than any in the PHP world.

Having said that, there are still valid reasons to stay with PHP in certain situations, even so the decision should not be too hard to make.

Re: RoR is not JUST for greenfield apps by Alexey Verkhovsky


just because it takes more lines of code to do Web applications in Java than in Ruby doesn't mean that it takes more time to do so.


Not necessarily, although well-written Ruby code tends to be easier to read than well-written Java code, partly because it is shorter, and it is shorter partly because the basic constructs are on average more abstract.

There are many anecdotal accounts of Ruby's better productivity, across a fairly wide range of projects. There are also almost no anecdotal accounts to contradict it.

Just recently, we (ThoughtWorks Canada) prepared a bid for some project that could be done with either ASP.NET or Rails. Rails estimate was about 30% lower. No, it's not 5 times :) But keep in mind that a software project is not just development, there is business analysis, system testing, infrastructure, deployment, project management, and so on, and so forth, all included in the estimate. It's not a three tables, five screens CRUD app, either.

What is risk defined as? by Ian Nelson

Risk that the project cannot be built? Risk that the project cannot be sold? Risk that the product has low quality? Risk that the product cannot perform? Risk that you're doing something different than everyone else? Risk of being ashamed for doing something different?

Market share doesn't really reduce some of those risks or really have anything at all to do with them.. Which risk does "language bloat" impact? Can you back that up with any evidence? Doesn't that contradict your thesis because Ruby has a lot more language features than Java does? While Java has a lot more libraries, is it the libraries that cause the bloat? I thought that as market share increased the increased access to libraries/gems and that reduced risk?

Is a new programming language inherently risky? It either works or doesn't, right? The risk is just how much you might have to do to make your project successful with it. You might have to write your own implementation of it, for example, like JRuby.

Seriously, this article isn't even consistent within itself. Is this the kind of crap InfoQ is really about? Bruce, you have anything to add? An apology? Or maybe take your name off it or something? Or maybe you want to take all the risk stuff out and just talk about how great Ruby and Rails is or something?

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

37 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