This week, I abruptly switched gears from working on a green-field Ruby project to pitching in on a well-established Java project. Revisiting Java provided a good chance for me to set down in words how we at Relevance think about platform choice. This week I will be posting a series of five myths that often misinform platform choices for new projects.
Myth #1: Ruby is suitable for small projects, and Java is better for large, complex projects.
This is exactly backwards. In fact, Java is more suitable for small, well-defined projects, while Ruby is better for large, complex, open-ended projects. There are several reasons Java wins for small projects:
- On small projects, finding the right open-source library often means you have nothing to do. Java has more libraries than anyone. Advantage: Java.
- The budget for a small project can be blown by a few gotchas that require unexpected development effort. Java is much better known and documented than Ruby. Advantage: Java.
- On small projects, teams don't have time or budget to acquire new skills. Most teams already know Java. Advantage: Java.
On a large project, all the factors above get reversed:
- There is a lot of new work to be done, so language productivity matters more than having libraries to choose from. Advantage: Ruby.
- Large projects are sure to have many gotchas, so you need maximum flexibility in responding to change. Advantage: Ruby.
- On a large project, retraining pays for itself. Companies grossly underestimate this. A five-week(!) training course on a technology that makes a developer 10% more productive would pay for itself in about a year. Advantage: Ruby.
If the myth is so backwards, why does anybody believe it? Ruby is, at present, exceptionally good at one specific kind of small project: database-backed web applications. Ruby on Rails counteracts all of Ruby's small-project disadvantages:
- Rails is the library you need.
- Rails eliminates the gotchas (for small projects!)
- Rails has a great out-of-box experience, so web developers need little retraining (for small projects!)
For web applications, Advantage: Rails.
People see the success of Rails and draw exactly the wrong conclusions. There are lots of visible, successful, small Ruby on Rails projects. There are lots of visible, successful, large Java projects. Look at these facts without broader context, and you get Myth #1.
Comments
Disclaimer: I haven’t worked on a Ruby project. I am a Java developer.
This post has a vague definition of “size”. It implies size as being the scope of a project and possibly the lines of code, but seems to ignore the social aspect: the number of developers.
I am highly intrigued by Ruby and love some of the concepts, such as open classes (see link below). But I wonder how dynamic languages work on teams with many developers? (let’s say more than 15, in 3 remote offices)
In my experience, the large the team, the more likely the chance for:
(a) junior developers without experience (b) morons without common sense
I know, I know: the answer is to “teach the former and get rid of the latter” but in practice this is very hard.
With this in mind, I wonder about some of the flexibility of the “new wave” of dynamic languages. As team size grows, does the “wild frontier” of dynamic coolness pose a threat to good development principles (in a social context) ?
To wit:
If organizing Java developers is like herding cats, perhaps organizing Ruby developers is like herding spider monkeys?
With large teams, it seems like the compiler and static analysis tools are your friends: they help to keep everyone “in line” which translates to productivity.
In short, perhaps Java is the new Cobol?
Boring, conservative, safe, disciplined.
just a thought… see disclaimer above. Mike
+1 for open classes (Neal Ford):
http://memeagora.blogspot.com/2007/05/are-open-classes-evil.html
your reasonings are seriously flawed.
Large project have to be scalable. Advantage: Java. Large project could be easily outsorced. Advantage: Java. Large projects must handle a lot of workload. Advantage: Java. Large projects should just work. Advantage: Java.
Interesting post… I haven’t gotten into Ruby yet but based on this post I might have a look. I am a little hesitant due to the lack of ruby open source libraries available though. I’m sure that will come with time.
“Language productivity” ? Why do you think Ruby is more productive than Java?
This doesn’t bode well for your other “myths”.
Hi!
I’ve been through that and I’ve implemented several projects with Ruby and Java. Some were small, others were large. I think I have to partly disagree with you somehow.
Ruby is definitely my favorite programming language of all times. It makes you really productive, it’s easy to read, understand and maintain and very, very powerful. Unfortunately, there’s a huge drawback out of using Ruby: the lack of a good tool like Eclipse that supports visual debugging, refactoring, auto-completition, etc..
So, and for large projects, I’m yet to decide whether the advantages of Ruby regarding productivity are not being restrained due to its lack of tools. My anecdotal evidence shows that the time wasted in doing refactoring or consecutively opening a class for checking a method’s name and variables is a huge waste of time.
Same applies to Rails, except for the fact that by using Rails a lot of work is leveraged out of the programmer so it makes this dilema even fuzzier.
Alex: Agreed on outsourcing-
Advantage: Java. I haven’t seen any Ruby outsourcing options yet. Disagreed on scalability-perhaps you do not know the definition of the term?I have to disagree! Large projects mean more less-than-average-quality developers (Ruby is much more difficult to learn for the average guy), need to have strong tool based refactoring support (not possible in Ruby), more compile time typechecking support (Ruby offers no compile time type checking), ability to construct rich domain models (Rails couples your persistence logic with domain model) and a rich set of libraries and frameworks (much more in Java than Ruby). Add to that the possibility of all exotic features like open classes and metaprogramming being ripped apart by the average quality developer team. I have to think otherwise.
Stu, Codegear is developing a new ide for ruby based on eclipse. Contact with codegear for beta test.
So presuming you can find enough programmers for a large project, requiring them to know Ruby means getting better overall quality programmers? :D
Debasish:
Refactoring is fully possible in ruby, google ruby refactoring rubicon
Also, rich domain models is easier with a DSL than anything else, and its not that hard to write a DSL in ruby.
Other than that I overall agree
I have to disagree on the point that Ruby has an advantage on large web applications (yet) – it depends how you define “large”.
Large team: As stated above, strongly typed / matured languages do have an advantage for large developper teams: Be it compiling, be it tools, etc. .
Large site (in terms of requests): Ruby (on Rails) is not known to be the fastest / most scalable programming language (platform) around, so sometimes the advantage of rapid development is gone (example: http://poocs.net/2006/3/13/the-adventures-of-scaling-stage-1 – the guy programmed 4 month in Ruby and needed additional 4 month to optimize the platform afterwards)
Large site (in terms of functionality): Yep, I’d say Ruby wins ;-)
Just my 0,02 $, Georgi
Scaling is definitely something to be concerned about and so is performance. Ruby running in the JVM is actually a great solution as is Groovy. Ruby’s threading is flawed to an extreme that makes it difficult to use in large parallel applications, especially large distributed applications that make heavy use of parallelism to reduce latency. However, Ruby should be getting a face lift on that front sometime soon (we are all hoping).
How about looking at this from the cost of staffing a team? Would you say that Ruby developers’ rate is cheaper than Java developers’ because they tend to be younger and the language is easier to learn? But on the other hand, there are more Java developers out there so it is easier to staff a large team. Want to get your thoughts on this, considering the talent pool in the SF Bay Area.
We’ve debate a lot on large projects. What about for small projects? Do we all agree on the author’s point that Java is better? I did Tomcat + Hibernate + Struts for a while, but haven’t touched it for ~2yr. I plan to work on a small Facebook app, 4 tables, some joins, 4 pages. Should I switch and take time to learn another language/framework?
“Language productivity” ? Why do you think Ruby is more productive than Java?
Because it takes about 5-10 lines of Java code to do what one line of Ruby can do on average. John Ousterhout’s famous scripting language productivity paper is perhaps the best known source of data, though it compares perl and tcl to Java and C/C++. However, the code density of Ruby is the same as perl within 20% or so, so the comparison is still useful data.