ONJava.com    
 Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples


Ruby the Rival

by Chris Adamson
11/16/2005

Bruce Tate's Beyond Java argues that Java's reign as the top enterprise development language must eventually come to an end and that, for the first time in a decade, major enterprise innovation is occurring outside of the Java realm. In the book, he looks at the unique traits that has allowed to Java to achieve its unprecedented level of success, and then considers what new languages would have to do and be to succeed Java.

Later chapters look at specific languages contending in this space, and clearly favors Ruby as the front-runner. This comes from Tate's own performance breakthroughs (fueled by Ruby on Rails), an analysis of the language, and anecdotal evidence from others who've tried the language.

Is Ruby already shaping up to succeed Java? What's broken with Java that Ruby fixes? And are the two mutually incompatible?

To survey the situation, we contacted several prominent authors, bloggers, and developers to get their takes. Their responses are reprinted in whole in this article.

Bruce Tate: Stirring the Pot

Bruce Tate doesn't come to Beyond Java as an outsider. His consulting company focuses on Java persistence frameworks and lightweight development methods, and he's the author of the popular Java books Spring: A Developer's Notebook, Better, Faster, Lighter Java, and Bitter Java.

1. You spend a lot of time on Ruby in Beyond Java, and it seems to be the front-runner among your "contenders" to succeed Java. What do you think gives it an edge over PHP, Python, etc.?

All are good languages, with some holes. PHP and Perl haven't consistently produced readable code for larger applications. Lisp, Python and Smalltalk have lacked the catalyst that great languages seem to need. Ruby is a good language, offering a compelling new value (in productivity) with a catalyst (in Rails) and what looks to be explosive growth. Ruby may not be the best language, but it's the most probable that I see. But it probably won't succeed Java across the board. It's likely to do well in a smaller niche first, but an important one: a big, fat relational database with a web UI.

2. Does Rails imply Ruby? Can't the same ideas be done in other languages, including Java?

Right now, Rails is that catalyst that transcends the language just as Netscape, with the promise of delivering applications via the internet, served as the catalyst for Java. But I think that Rails may possibly be the first of a wave of metaprogramming frameworks in Ruby.

3. The Ruby success cases seem to be small projects of just one or two developers, the typical "connect a web interface to a database" scenario that you base a lot of the book on. But you also acknowledge the value of Java's heavy-duty enterprise frameworks to a certain set of projects (e.g., big apps on big iron). At what point does a project get too big for RoR? What happens if an RoR project feature-creeps in that direction?

Related Reading

Beyond Java

Well, you can do a lot with Ruby and small teams of people. Base Camp was basically written with one person, and it's a bread and butter application for a whole company. We won't know how far you can push Ruby or Rails until some major companies get serious about trying. One of the things that's the most interesting to me is the economy of scale--smaller scale. What if the productivity numbers are real? What if you really can get a 5x boost? Then, you can do the work of divisions with a department, and the work of departments with a team of two. Communication becomes less of a problem. Management and oversight are less of an issue. We all know what the tipping points are for growth in a company. It's hard to scale past one, five, ten, 40 and 100. These are all barriers to growth based on adding new levels of communication and management. But intellectually, Ruby on Rails scales very, very well.

4. Do you see Java developers transitioning to Ruby, or is Ruby going to be adopted by a new generation of developers?

I think both. There are developers that can't stomach learning servlets, Spring, XML, Hibernate, Struts and then some UI glue frameworks. They're going to be unleashed in Rails. There are also Java developers who are already looking for more leverage and finding it in Ruby on Rails. The number of Java visionaries adopting Rails, from Thought Works to James Duncan Davidson to Stuart Halloway to David Geary, is staggering.

5. Isn't there anything Java can do by itself to maintain its prominence? If the complexity and bloat is such a problem, what's to stop developers from just rolling the clock back to JDK 1.4 and staying there?

Java will do fine in the enterprise for a number of years on the top end, but time rolls on. It will be replaced at some point. We're going to need a higher abstraction. The best we can hope for is a sound investment in the JVM for dynamic languages to embrace the new, and to continue the conservative stewardship of the language to support the millions of lines of Java code, I think.

6. Should we expect to see Ruby make a splash in other fields? If it's so great for developing web apps, would it be useful for desktop apps if there were a suitable UI framework it could call?

It's much too early to say. Ruby is but one candidate, though it's the language with the catalyst behind it right now. What happens next? I don't think anyone knows.

James Duncan Davidson: Trying Something New

If you use Tomcat or Ant (and seriously, what Java developer doesn't?) then you're familiar with James Duncan Davidson's work. At Sun, he was instrumental in open sourcing these projects and donating them to the Apache Foundation. He also authored the first two versions of the Servlet API, as well as the Java API for XML Processing. After leaving Sun, he took up Mac OS X development, authoring Running Mac OS X Panther and co-authoring Running Mac OS X Tiger, Mac OS X Panther Hacks, Cocoa in a Nutshell, and Learning Cocoa with Objective-C, 2nd Edition.

1. Last we saw of you, you were the "Mac desktop apps in Cocoa" guy. Now I see on your blog that you're heavily into Rails. How did that happen?

I was poor and desperate and needed the cash. I'd just bought a new house and my mortgage payment was coming due--oh wait, you want me to be serious? Well, the truth of the matter was that some friends of mine and I have been wanting to work together for a while. And when the time was right and we did the technology evaluations for the project, Rails came up on top. And this was even before I'd used Rails or Ruby. But I wasn't about to let a little required learning keep me from doing the project. I've learned three, maybe four languages this year. I no longer believe in one language to bind them all. If I need to learn a new one to do something, I'll buckle down and learn it.

2. What got you looking at Rails?

Simplicity, mainly. The ease at which you can get things done. The application that I did the first project on was originally a Java-based web app. Everyone in the room knew that there had to be a better, faster, easier way. Ruby has always been a good language--and an interesting one to boot--so to see this framework built on top of it, well, it deserved attention.

3. Has Ruby's obscurity and Rails' newness been a problem with customers/clients?

Not really. In fact, right now, it's the other way around. There's too many potential jobs and not enough people that have really shipped real Ruby on Rails applications.

4. Why is Ruby so special? Couldn't Rails have been done in some other language? Couldn't it have been done in Java?

There are a few other languages in which you could have done Rails, or rather something like it. Java isn't one of them. Rails gets a certain je ne sais quoi from Ruby and to attempt to exactly duplicate it in another language would be both a loss to what Rails does and to that other language. But certainly the concepts can be well applied in other highly dynamic, dynamically typed languages.

I'm excited, actually, to see other projects implementing some of the ideas that have come out of Rails into other platforms. For example, Django gets a bit of static as a Python copy of Rails, but really, it is it's own beast and it'll be interesting to see how it grows.

Now, I've said that you can't do Rails in Java. That doesn't mean that you couldn't do something equally as cool in Java. The strengths of Java could be applied to a brand new framework in interesting and amazing ways. It's just that nobody has done that yet. Everybody has been too interested in chasing the J2EE cookie to rethink the problem in a drastic and dynamic way. But even if somebody does come up with a killer Java-based web framework that does as much as Rails, it certainly won't look or feel like Rails.

5. Well-designed Java apps survive feature creep pretty well--design your classes and packages well, and you're good for a long time. Can a team write a really big Ruby app? Will it be maintainable? Or is RoR meant for the small consulting gig?

Well-designed applications in any language can survive feature creep well. Badly designed applications in any language don't. There's also the matter of a definition of a really big application. The first Ruby on Rails app that I wrote was deployed into production with less than 5,000 lines of code. I've built the same caliber of application before in other languages and it took 50,000 lines of code. So defining big is a problem.

Can a team write a Ruby on Rails app that performs a large number of features, does it well, and is maintainable over time? Yes. No question. After working with Ruby on Rails for a while, I would be confident tackling any size web application problem with it. But, that's because I've spent some time with it and now have seen that it's possible to write a well-designed application.

That said, there are probably dozens of crap Ruby on Rails applications being written right now. Hundreds or thousands, maybe. If you don't know what you are doing, it doesn't matter what tool you use; you'll write a crap application.

6. So we're back to the web app. Could you use Ruby on the desktop, or are we forever doing our UIs in C#, Obj-C, or whatever the OS vendor blesses?

Well, one part of my life is back to the web app. It's a comfortable spot for me, as I've been doing web-based work since 1994. But I continue to work on desktop-based ideas and applications. And there's still a wide need for them. I don't want Office on the Web. And you certainly can't build something like an Aperture as a web app.

Could you use Ruby to build a compelling desktop application right now? No. The toolkits don't exist for it. But if the right toolkit were there--it's possible. There's nothing about the language that keeps it from being a good desktop application language. That said, I've found that the best way to take advantage of a platform, whether it's an operating system or a web application framework, is to be as native as possible to that platform. For my desktop work on the Mac, that still means writing with Objective-C and using Cocoa. For my web work with Rails, that means using Ruby. For system work, that means C and shell. There is no single answer in this discussion.

And I think that's the real win from the recent attention on Ruby on Rails and the breakaway from viewing the world with Java-colored glasses. It's not that Ruby on Rails is going to be the next Java. Far from it. It's that Ruby on Rails helps to break this idea that there is "One True Way." There's not. There are many different ways to solve a problem. And really, none of them is the clear-cut winner. There's just places where one solution has advantages.

It's like the structures that we work, eat, and live in. Some structures are best built with concrete and steel. Others with masonry. And yet others are best built with timber. Nobody has jumped up and said "All buildings must be built with bricks!" And there's a good reason for that. It'd be stupid. In a similar vein, not all web applications should be built with Ruby on Rails or Django or J2EE or Perl. There's a multitude of tools for any particular job. And there are new ones waiting to be discovered. The trick is determining the best one.

To bring this rant back to your question: in the web application space, it's easier for new frameworks to come along because you're not dealing with things like video cards and GUIs and the overall system in which the application runs. But unless you are willing to build your own framework, it's still a decision as to which one to use. It's the same way on the desktop. You could build your own framework and do whatever you want, but it's a harder proposition than to build a new framework for the Web.

Robert Cooper: Bringing the Hammer

ONJava blogger Robert Cooper recently reacted to some of the "Java end times" talk with his blog entry "It's the End of the World as We Know It." Cooper is an Atlanta-area J2EE developer working on enterprise integration and web/web services applications, and a proprietor of the informative and amusing screaming-penguin.com site.

1. You've said that "The sad truth that 'Enterprise' Java has missed for so long, is that even in the 'enterprise' only one in 500 applications need 'enterprise' functionality." Why would Java developers adopt more sophisticated frameworks than they really need?

Well, there are a couple of things that go to this. One is "buzzword compliance." You want to use what you are "supposed" to be using. I remember back in '99 doing a couple of big projects using entity beans as our data model, where we promptly found out the performance was so horrible we ended up switching back to a hand-coded DAO layer. However, the EJB 1.1 spec at the time was what we were presented with as being the "solution" from the powers that be.

The failure of EJB through the recent changes to javax.persistence, however, has always been the lack of sliding levels of support. Ideally, the framework should have been structured so that if I just wanted basic, easy ORM-type functionality, I should be able to get there quickly. Only then, if I wanted to get into the seriously complicated stuff, present me with a "deeper" view that has distributed transactions. However, even at that top level, look at how many lines of code you need in the EJB 1.1/1.2 world to 1) get the Home stub from JNDI, 2) do a find by, 3) make a change, and 4) commit a transaction. There is no reason that for the average application the answer to that shouldn't be "two." While newer Java frameworks (read: Spring plus Hibernate) get you to that "two," you have to juggle a whole lot of configuration to get there as well. That, in a lot of ways, muddies up your code. A lot of that goes to my "have a workable default configuration/operation" rant, but that is a different story.

2. You've scoffed at Ruby on Rails as "the deification of the next great thing among the technorati." Do you not buy it, or are you just sick of the hype?

It's not that I really scoff so much. Rails is great in a lot of important ways. In fact, if the Flying Spaghetti Monster™ that PHP is would die and be replaced by Ruby, I think that would be a huge step forward. However, for all Ruby does clean up the mistakes of the past and present a compelling new development model for the quick and dirty, it does lack the "deep bench" of functionality that Java has. You might argue that this is simply a matter of time, and it could be. Mostly, however, any hostility I feed toward Ruby/Rails has to do with the features I have wished Java had for a long time and a simplicity of development that I have wished J2EE had for a long time.

3. So what's keeping you in Java, and what works for you?

Well, in terms of my day-to-day work, there is no invoking PCML/RPG programs on the 400 from Ruby. Also, a lot of those actual "enterprise" features that Java has are important, not the least of which is a unified packaging and deployment framework.

4. You say "However, Java seems to have become an also-ran in every possible category. It is not 'the language of the Web,' nor is it a 'first-class citizen' in the desktop." Should Java abandon some of its ambitions and focus on a smaller set of application spaces? If so, which?

You know, I had a long back and forth on my site with a gentleman about this. He noted Java's success in the J2ME world, the TME/TiVo stuff, the set-top box and perhaps the still-a-dogfight next-gen DVD spec. These are all valid spaces for development, but I think if Java just became this kind of system, it would be a loss.

What irritates me is that in the "applet" space that Java invented, you look at Flash(plus Flex/Laszlo) and it crushes applets in both "cool" (get me to a good user experience quickly) and "powerful" (I get data binding/SOAP/XML-RPC/etc. for free). The fact that the "powerful" side of that isn't in the core JRE immediately kills the usefulness of applets, and if anyone can show me an applet that looks anywhere near as good as the Laszlo Dashboard demo in a similar number of lines of code, I might have a coronary on the spot. "Cool" counts for a lot, too.

5. A lot of what you've criticized is Java's increasing complexity, and multiple competing frameworks. Would we be better off coding JDK 1.2 syntax and writing servlets by hand?

My problem with complexity is that it is rarely managed. If you start to look at Swing, for instance, coming from a VB background, it is horribly imposing. There isn't a "simple" interface that you can then cast to more "advanced" interfaces when you need to do something tricky. That is one part of it. The other part is that while these frameworks all have their places, the JRE itself needs to start absorbing some of them into the core so there is at least a "default" way of doing things. Frankly, the last time that happened with anything useful was the JAX-P stuff. There is also, in my mind, a large swath of stuff that is still missing from the core JRE that needs to be there--how old is Swing now, and there is still nothing that gives you the functionality of the VB5 data-bound table control.

I think the JDK1.5 language enhancements are great, myself. When I talk about "reducing complexity" though, what I really mean is A) giving more standard ways to do something so that I only need an external framework if I really need the feature differentiation, B) design APIs so they are more approachable--seriously, look at the JavaDoc on JavaMail and see how long it takes you to figure out how to send an HTML-formatted email, and C) get more of the "common" functionality into the core runtime and offer a style and performance that is comparable to Flash-based or Avalon/Sparkle of the RIA and desktop spaces, respectively. That is to say, I'm not asking for less, I am asking for more and better. In the same way, I remember fondly moving from the VB/VC++ world to Java and thinking, "Gee, it should have always been this way," several years ago, I can't say I look at anything that has been added to Java (with the exception of the forthcoming JAX-WS API) and had that same thought. Looking at Rails, you get that feeling. Looking at Flex you get that feeling. Looking at Avalon you get that feeling. It isn't that I don't like Ruby, it is that I am frustrated that Java doesn't seem to be keeping up.

Bill Venners: The Publisher's View

Artima is a highly regarded bookmark in many Java developers' browsers, and its publisher, Bill Venners, is a longtime Java author and consultant. He's also been a JavaWorld columnist, and author of Inside the Java Virtual Machine. So when we noticed Ruby content on Artima, we had to find out what was behind the change.

1. Artima sticks in many people's minds as a Java site, yet you just opened up a new Ruby section, and it's what most of Artima's current feature articles are about. What prompted the switch?

There has been no switch. Artima was historically a Java-only site, but a few years ago we broadened the focus to development in general, and started covering other languages. We syndicate Python blogs in "Python Buzz" and publish C++ articles in "The C++ Source," for example. We created the Ruby Code & Style zine to serve as a place the Ruby community could share information through high-quality, edited articles.

2. Do you think of your Ruby coverage as anticipating a trend, or servicing developers who are already making the switch?

We created the Ruby zine merely to serve the Ruby community. I don't know whether there's a trend, and I don't see many Java developers "switching" to Ruby. People needn't only program in one language. I think it is good to know a systems language, such as Java or C++, and a scripting language, such as Ruby or Python, and be able to work in both. That way you can use the best tool for the job at hand.

3. Your first few Ruby articles say almost nothing about Rails. Do you think there's a major Ruby story beyond Rails? What other kinds of things do you see it being used for?

I don't know much about Rails other than that it has been well marketed. The Rails marketeers drummed one message over and over, that Rails helps you build web apps quickly. Everyone has received this message loud and clear. It was a very good job of marketing, in my opinion. I believe the message too, but getting a green-field design web app out the door fast is not the only concern people have. Integrating with legacy databases, scaling to a cluster of app servers, are also sometimes concerns, and in such cases other tools may be more effective than Rails. As far as Ruby is concerned, I see it is a general-purpose programming language that is suitable for scripting and building systems, much in the same category as Python.

4. Even before Rails, people were talking about Ruby as being uniquely appealing to Java developers, compared to some of the other "agile" languages. What's special to you about Ruby? Why is it so good for Java emigrés?

I don't believe there are many Java emigrés, or that Ruby is especially suited for Java programmers. There's a bit of hype surrounding Ruby now, perhaps because of the Rails marketing, so perhaps your impression of emigration comes from the hype. Ruby is a nice language, but so is Java, and so is Python.

5. Do you think we're going to see a lot of Java developers picking up or even switching to Ruby, or will we see a new generation skip Java and use Ruby instead?

Java is not going away. At Artima, we chose Java for the new architecture over Ruby or Python because it is a mature ecosystem with a lot of tools and APIs, both free and commercial. Yes, there are fewer speed bumps when programming in Ruby or Python compared to Java, but with the modern Java IDEs like IntelliJ, Eclipse, and Netbeans, you can really move quite fast in Java. But Ruby is quite enjoyable to program in, and if someone finds they can build a career out of Ruby programming, then by all means do so.

6. Anything else you'd like to say about Ruby and Artima?

Only that we don't really care about hype. Don't read anything into our creating Ruby Code & Style other than we would like to serve the Ruby community in addition to Java, C++, Python, and other communities.

Conclusions

Is Ruby about to sweep Java aside? Not even the loudest Ruby partisans are predicting such a thing. What we do see in our correspondents' comments is the consistent idea that developers need, as Venners puts it, "the best tool for the job at hand." Crucially, developers are responsible for understanding and using those tools correctly. It's not hard to see the connection between Cooper's memories of EJB 1.0 hype and Davidson's prediction that "there are probably dozens of crap Ruby on Rails applications being written right now"--getting swept up in marketing can be dangerous, regardless of the technology. Nevertheless, people in the know who've tried Ruby are reporting significant productivity boosts, so there may be jobs for which it is indeed an ideal tool.

The author would like to thank Bruce Tate, James Duncan Davidson, Robert Cooper, and Bill Venners for taking the time to share their ideas with the ONJava audience.

Chris Adamson is an author, editor, and developer specializing in iPhone and Mac.


Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.