Friday, September 5, 2008

Java vs. Ruby on Rails - It is a Dead Heat

Java and Ruby on Rails will be the focus of this article because they are what I know best...

For web technology entrepreneurs in the process of developing a new online service, there are five important choices that must be made regarding web technology. Some of the following choices have options that are mutually exclusive and others that are inseparable. I put server side language first, since in many cases it narrows down the options for the remaining choices:
  1. Server side language: Java, Ruby on Rails, PHP, Python, ASP.NET or other
  2. Database: MySQL, Oracle, PostgreSQL or other
  3. Web server: Apache, IIS, or other
  4. Hosting environment + hosting service: Windows or Linux + Rackspace, Amazon EC2, Google App Engine, or other
  5. Developer tools: Eclipse, .NET Visual Studio, or other
The issues and pressures web technology entrepreneurs balance when making the aforementioned choices typically have this priority:
  1. Time to market: how long will it take to program the desired features, configure the hosting environment, and deploy the software. Some ideas need to be implemented quickly to capitalize on a time-sensitive opportunity. In addition, the sooner you receive feedback from your user base the sooner you can adjust your business model.
  2. Costs: on a tight budget, free open source software and cheap shared hosting environments are attractive. On the other hand, the licensing costs of enterprise servers and support may be what you need to scale your system.
  3. Long term scalability and growth: how many users can your technology mix support, will you need to switch hosting environments to support a rapid increase in user activity, and how quickly can new programmers learn and be productive with your technology?
I am going to focus on the server side language choice because I believe it has the greatest impact on time to market, costs, and long term scalability and growth. Before analyzing both Java and Ruby on Rails, I will attempt to build some credibility (albeit outdated) in this discussion...

My Java Background

From 2000 to 2006, I was a professional Java programmer with four Sun Certifications: Programmer for the Java 2 Platform, Web Component Developer, Developer for Java Web Services, and Enterprise Architect. At the end of this era, I was using Java with Struts 1.2, Oracle 10g, IIS with Tomcat, Windows servers hosted at our company data center, and Eclipse. You can view my outdated java.net profile or my updated LinkedIn profile.

My Ruby on Rails Background

From Fall 2006 to Spring 2008, I was a full-time MBA student performing the web programming and managing the hosting environments for the entrepreneurial ideas my classmates and I came up with. Most of the time was spent creating unsuccessful Facebook applications. In this time, I chose to use Ruby on Rails, MySQL, Apache 2.2, Amazon EC2, and Eclipse.

Java vs. Ruby on Rails

In a nutshell, Java is not good for entrepreneurs because it is too complex and too slow to develop, configure, and deploy your web application. Ruby on Rails will get you off to fast start because it excels at time to market and low costs but leaves you hanging when it comes to scalability. Here is my entrepreneurial web technologies report card:
Time to Market:
  • Unit testing: both Java and Ruby provide comprehensive unit testing frameworks for testing objects.
  • Controller testing: I give the edge to Ruby on Rails because you can test your controllers (including aspects of your view templates) side-by-side with your objects without having to rebuild or recompile the rest of your web application. The Cactus Servlet testing framework and StrutsTestCase are not as easy to use as Ruby on Rails' controller testing framework.
  • Rapid feedback: Since Ruby is a scripting language you do not have to recompile (i.e., Java) your code in order to test your changes.
  • Code conventions: Ruby on Rails epitomizes the use of conventions while Java has lots of competing frameworks (e.g., Spring, Struts, JSF) that each like to invent their own conventions.
  • Developer tools: Eclipse offers outstanding developer tools for both Ruby on Rails and Java. Eclipse has slightly better tools for Java including more comprehensive code completion and code generation.
  • Code library complexities: Ruby requires much less thinking when comes to installing plugins, third party components, upgrades, and other libraries. Java library compatibility can be a circular (tail-chasing) mess, especially regarding XML libraries (i.e., JAXB, Xerces, Crimson). Specifically, it can get complicated trying to figure out the order that XML libraries are being loaded into the Java classpath. For example, I used to struggle to understand which versions of Java, Tomcat, and the web services libaries were compatible with each other. Upgrading one of the three might cause a problem with one of the other two. Ruby gems, albeit not flawless, makes it really easy to add and install new libraries and, what's more, the gem tool will prevent you from installing incompatible libraries.
Cost:
  • Software Licensing: Java and Ruby on Rails are can be configured to use 100% open source software and, thus, be free to use forever. However, it is likely that a successful online service will eventually need proprietary software regardless of your server side language. I give the higher mark to Ruby on Rails because Sun allows its proprietary enterprise partners to lead the way with many of the enterprise level software solutions requiring subscription or licensing fees (e.g., JBoss, BEA/Oracle, WebSphere).
  • Hosting services: In my experience, hosting Ruby on Rails is cheaper than hosting Java web applications but that both come a distant second to PHP hosting.
Scalability and Growth:
  • New developer learning curve: as a result of code conventions and limited code library complexity, Ruby on Rails has a much flatter learning curve for newly hired programmers. Specifically, a new developer can get up to speed with a Ruby on Rails web application really quickly by simply reading this book: Agile Web Development with Rails, 2nd Edition
  • Multi-threading: Java application servers allow you to run multiple web applications in a single process with the single process managing the multi-threading with minimal configuration. However, Ruby on Rails mongrel clustering requires that each web application have its own static number of mongrel threads. This a problem because the server's memory use is very inefficient. Specifically, a static number of mongrel processes for each of your rails applications means that daily or hourly fluctuation in site traffic could max out your one of your mongrel clusters or at the very least put an unbalanced load on one of them.
  • Service up-time: during deployment of an updated web application, some of the Java application servers can "automatically manage client connections so that existing clients continue to use the older application, while new client requests are directed to the newer application". On the other hand, anytime I installed an updated Ruby on Rails application, there would be at least 30 seconds where all of my mongrel clusters (i.e., multiple Rails applications) would be out of service. Obviously, I may not have been doing things the best way possible but the point is that Java makes it easier to maintain service up-time.
  • Clustering: In conjunction with multi-threading and service up-time, Java application servers provide comphrensive clustering capabilities whereas Ruby on Rails requires duct-taping Apache and Mongrel together.
  • Command line scripting: for data backups and other asynchronous processes has proven to be unchallenging for both Java and Ruby.
  • International language support: Java has native support for creating web sites that need to serve multiple languages. On the other hand, I have yet to see any international language support from the Ruby on Rails community. If I was going to do a multi-lingual web site, I would not choose Ruby on Rails.
It is a Dead Heat

The results of my entrepreneurial report card show that both Java and Ruby on Rails score a grade point average of 3.07. The report card GPAs resulting in a tie is merely coincidence and is not a product of report card manipulation.

More importantly, Java and Ruby on Rails can both fail you; albeit in different ways. Ruby on Rails can fail you on scalability and Java can fail you on time to market. On the other hand, Google's App Engine is very intriguing because it guarantees scalability and low costs. Unfortunately, it appears to sacrifice time to market because you have to learn and use Python. Specifically, Google encourages you to use their Python webapp framework. Therefore, expert Python developers using Google's App Engine may be able to score straight As on my entrepreneurial report card. Other than that, there does not appear to be a combination of technologies that can score high marks on all of the aforementioned entrepreneurial issues.

Summary

My assessment of web technologies is intentionally narrow because entrepreneurs do not have time to experiment with all of the latest and greatest technologies. Instead, entrepreneurs have to either stick with what they know or quickly decide on a new technology and run with it. Further, there are many entrepreneurs without web programming experience that have to take an even bigger risk by letting hired consultants make these choices for them.

If you have a tight budget regarding time and money then Ruby on Rails is your answer because of its ability to provide rapid feedback. However, if you have time and money then Java is more likely to grow with your business. In any case, both technologies can fail you because the perfect entrepreneurial web technology mix has yet to emerge and, thus, the quest to lower entrepreneurial barriers-to-entry must continue.
Posted by Robert J Miller

21 comments:

  1. Great article. I've heard that using Java can be troublesome, is that what you mean when you say it can be more expensive?
    ReplyDelete
  3. Comparing Java vs Ruby on Rails is not fair, u need to compare Ruby on Rails vs specific Java framework, like Grails (www.grails.org), JBoss Seam, etc

    For point:
    -Code Library Complexities -> Grails is simple like Rails
    -Code convention -> Grails using groovy language that simpler like Ruby and using DRY and Convention over configuration principle
    -New Developer Learning Curve -> Grails make it easier
    ReplyDelete
  4. Hi. You've written a nice article and you've obviously taken the time to research things. Unfortunately for this article, it's a bit outdated. A lot has changed in the Ruby on Rails world in the past 6 months, and the fact that these new developments are not included in the article is probably because you haven't used Rails since spring 2008, as you've mentioned.

    In April 2008 and June 2008, Phusion Passenger and Ruby Enterprise Edition, respectively, were released. These two products, along with improvements in the Rails framework itself, have reduced or eliminated many of the Rails shortcomings that you've mentioned in your article. To be specific:

    Multi-Threading:
    Phusion Passenger is an application server for Ruby on Rails for Apache. It manages Rails processes dynamically, based on the current amount of traffic. If there is no traffic, then memory usage is near-zero. If there is a lot of traffic then it will spawn up more Rails processes to handle the load. Though only up to a specific maximum, so that your server won't die from memory exhaustion.
    Furthermore, Phusion Passenger, when combined with Ruby Enterprise Edition, allows the server to take advantage of "Copy-On-Write" memory optimization techniques. Even though processes are used instead of threads, thanks to copy-on-write, a lot of memory is shared between these processes, thus yielding memory efficiency comparable to when threads are used, with the additional benefit that the application code (and any used third party libraries) doesn't have to be thread-safe. If a process crashes then it is automatically restarted.

    Furthermore, Rails 2.2 will be thread-safe. So application servers other than Phusion Passenger can benefit from multi-threading in the future.

    Service uptime:
    When the Capistrano deployment automation tool is used in combination with Phusion Passenger, deployment downtime can be reduced to near-zero. Capistrano deploys the application to a unique directory, so during deployment the already running Rails application is not affected. When deployment is done, only changing a single symlink and (gracefully) restarting Apache is required. Phusion Passenger's process management technology allows 30 Rails processes to be started almost just as fast as starting a single Rails process.

    Clustering:
    See multi-threading. Although I don't understand why you called Apache+Mongrel "duct-taping". Could you please elaborate on this a little more? Apache proxies to multiple Mongrel instances, but to me this seems to be the same as all other forms of HTTP proxying, including letting a load balancer proxy to one of your web servers. So I don't see why this is considered duct-taping.

    I18n support:
    Yes, it's not great at the moment, although there are already a number of I18n plugins which provide usable I18n support. Better support for I18n in the core Rails framework is being developed as we speak.

    Hosting services:
    Since the release of Phusion Passenger, many many shared hosting providers have started providing Rails support. This includes Media72.co.uk, Dreamhost and Railsmachine. Dreamhost offers Rails hosting for only $10/mo, just like PHP hosting.


    I appreciate the time that you've spent into your article, but the developments in the past 6 months are huge, and it's a pity not to see them included in your article. So I'd like to ask you to consider updating your article with this information. Thanks.
    ReplyDelete
  5. Hi. You mentioned Visual Studio in your introduction but you didn't mention our Ruby In Steel IDE for Visual Studio. This has full analytical Intellisense, a very fast integrated debugger, a drag+and+drop designer for Rails applications and all the other things you'd expect in Visual Studio.

    best wishes
    Huw Collingbourne

    SapphireSteel Software
    Ruby and Rails In Visual Studio
    http://www.sapphiresteel.com
    ReplyDelete
  6. As Hongli said, deployment isn't as much a pain anymore, thanks to mod_rails. Also, with rails 2.2, we at least HOPE you won't need quite as many resources.

    Django also might get even higher ratings than what you've given these two :)

    And also, re: testing--look into spec--it's quite nice :)
    ReplyDelete
  7. Also you've missed out on a few developments in the Java space. Unit testing of controllers is now easily possible using either Spring MVC or Struts 2.x.

    I also think deployment in Java is much more controlled using single deployment units (WARs/EARs).

    I'm currently developing using both platforms and have run into a lot of the same differences - I initially liked the speed of development with Rails but find the odd thing you need to do that breaks the convention is really painful.

    I've been hearing some really good things about JRuby so I need to take a look as this may be the best of both worlds.
    ReplyDelete
  8. Kevin, I think the most troublesome aspect of Java is that since there are so many ways to accomplish the same goal, that each Java programmer may code same project differently. Thus, if you hire a new Java programmer, he/she may struggle to learn and add features to another person's code. This risk can be reduced by hiring new programmers with experience using the web framework that you project is currently using (e.g., Struts, Spring) but you will need consider what object-relational framework being used. Thus, it can be tough to hire a new Java programmer who is experienced using your exact technology mix (i.e., web framework, database framework, and application server). However, since Ruby on Rails is a conventions-based framework, each new programmer should be able to jump right in and start coding.
    ReplyDelete
  9. Sam, thanks for tip. Rails localization looks promising.

    Grailsdeveloper.com, thanks for the tip about Grails...I need to look into it.

    Hongli Lai, thanks for the Rails updates as I have not been programming since May 2008 :(. Phusion Passenger sounds like a big improvement. I consider Apache-Mongrel duct-taping because it takes such a long time for a set of 20+ mongrel thread to shutdown and restart. In addition, you have to manually configure the ports for each rails application you are hosting which is cumbersome when hosting 3+ rails applications. I make no assumptions that I was doing things the most efficient way. Thanks for the hosting tips too. I really like Amazon EC2 and can now see that future Rails hosting using Amazon EC2 will be much easier.

    The Chronicler, thanks for the Ruby In Steel IDE for Visual Studio tip.

    Roger Pack, mod_rails looks like the solution to my hosting and deployment issues! Thanks for the info. Are you saying Django has good unit and controller testing?

    Stephen, thanks for the comment. Although my Java controller testing experience is 2 years outdated, I still believe that Java programmers are more likely to "muddle/butcher/make messy" Java controller testing than Ruby programmers doing Ruby controller testing. Unfortunately, Java facilitates a greater variance in coding practices and conventions that make working on a Java team more stressful. Although, I do agree that Rails can be frustrating for the outlier scenarios. Java is good for larger companies because of its vast capabilities and Rails is better suited for smaller companies needing to enter a market quickly.
    ReplyDelete
  10. Oh by the way, in case you didn't know, mod_rails and Phusion Passenger are the same thing. :)
    ReplyDelete
  11. Joyent is an excellent platform for Ruby, Python, PHP and Java apps. Their developer tools include Joyent's Accelerator network of multi-core, RAM-rich servers and storage devices. In terms of scalability, just look what Joyent did with Linked In's Bumper Sticker app for Facebook: Over one billion page views per month. They are also the official host for Ruby on Rails.
    So in a nutshell, Joyent is a great alternative whether you are using Ruby or Java. I would love to see them added to your report card.
    ReplyDelete
  12. I know it's been said, but if you are an experienced Java developer and you have not taken some time to learn Groovy and Grails you are doing yourself a major dis-service. You really should look at Groovy and at Grails since the project is tailored to bring some Rails' advantages to you while letting you keep the advantages on the Java platform.

    Yes, there are still Java platform disadvantages such as hosting but if you need that internationalization or multi-threading then Groovy and Grails destroys those low scores on the Java side of your score card without touching the high scores. Putting Java + Groovy + Grails together creates a winning ticket that is easy to learn, simple to work with and can fall back on Java when scaling and clustering issues arrive.

    And it's ready NOW.
    ReplyDelete
  13. So many of the mentionned "disadvantages" could be good things...

    Compilation is one of them. ROR is some kind of language/framework where you write a small quantity of code, test it, write some more, ... A lot of time, I write 5000 lines of java code before I even try to run it... and I know there is a good chance it will work for the first time. Static typing, compilation and such help me write good code from the beginning.

    Ok, making fancy little things is fast in ROR (or php, or whatever script toy), but Java, C#, ... are just professional tools. It tends to ask more attention from the developer, you have to think about some real architecture and design.

    Ok, I know you could write spaghetti code in java, many of my colleagues do... But it's more difficult ;-)

    Also, one kind of important thing java has is specifications: EJB, JSF, ... The spec is there (and open!) and there are a lot of implementations. I don't see any mention of this here (I never see that in this kind of java vs xxx comparison), although it is quite important.

    Sorry about that, but by ignoring it, I think you're just another spaghetti coder.
    ReplyDelete
  14. I think was a very fair and well thought through article. Thanks. It confirms what I've been beginning to feel over these last few years. Yes Java has a steeper learning curve, perhaps (although for those of us coming from the SE world, it's not *that* bad) but Rails still falls very short when it comes to scalability - making it in my opinion, a bad choice for enterprise applications. I do like some of the features of Rails but if there's one thing I can't stand it's the 'fan-boy attitude' that goes with it, which is blinkered and doesn't address real business needs properly.

    'Google's App Engine is very intriguing because it guarantees scalability and low costs. Unfortunately, it appears to sacrifice time to market because you have to learn and use Python.' - did you know they've just started supporting Java - going to keep my eye on that, sounds like that will change everything...!
    ReplyDelete
  15. Yes, I have been using Google App Engine for Java for about a month and it definitely solves the scalability problem. It does not support the full JVM so some people are upset about that but it supported everything I needed to do and the Eclipse plugin makes deployment really easy.
    ReplyDelete
  16. I'm an entrepreneur who's working on their first Web app. Just wanted to say thanks a lot for this article - really helpful.
    ReplyDelete
  17. thanks a lot for this article, but are you using ruby1.8 or 1.9 ? because ruby1.9 gets a lot of new features.
    ReplyDelete
  18. As an Entrepreneur
    Are we saying that its best to choose either Ruby on Rails or Java for an online app ? (forget the others)
    At what point (terms of number of visitors / transactions per second etc are we saying that Java is more suited. Just trying to get a feel for the scale... (we would all love a facebook site but one step at the time)

    Also any thoughts on hosting, do we go with a dedicated box or use heroku or amazon direct ?

    What about security and robustness ?

    Thanks
    GG
    ReplyDelete
  19. George, at this time, I recommend Java and hosting it on Google's App Engine for Java because Google will manage all of the scaling issues and make security easy to implement. However, you'll need to research to see if App Engine supports all of the Java libraries you plan to use. In the past, I've successfully used Amazon's hosting service for Ruby on Rails.
    ReplyDelete
  20. Thanks Robert

    If your developer is dead set on Ruby on Rails (I guess that is what they know best) should i look elsewhere. If it was a case of a toss a coin i would stick with him.

    If we are going down the Ruby on Rails road what would or anyone else suggest about hosting.... Dedicated box, Amazon, Google. (Is clould overrated, the developer said to start with a dedicated server but i think there is nothing worse than poor performace / load times especially for a start up)

    Thoughts ?

    Thanks
    G
    ReplyDelete