Today we will discuss some of the reasons that companies may consider looking past the lack of RoR’s market penetration.

Useful resources

Enterprise Integration with Ruby by Steve Vinoski is worth reading as it depicts how some project managers and developers use the phrase "enterprise integration" to give an artificial boost to projects, or as an excuse for a project failure (in reality they were late, over-budget or unable to deliver required functionality).

In Enterprise Integration with Ruby, Vinoaki’s treatment of enterprise integration is eminently practical throughout. For example, he uses the term “enterprise” to mean systems that incorporate multiple technologies and approaches, such as databases, the Lightweight Directory Access Protocol (LDAP), XML, messaging, Remote Procedure Calls (RPC) and distributed objects. If you need to glue such things together, Maik Schmidt also wrote Ruby as Enterprise Glue .

Newbie in the zoo

Any new technology does not have significant penetration at the beginning. Let’s take a look at Java from the beginning, back in the days when Java was said to be the "slow language" and, for very few years, it just existed. Although designed with a different objective in mind, Java found a perfect match in the World Wide Web but it was not supported by all web browsers. Later on Netscape Inc., followed by Microsoft announced that they would incorporate Java into their web browsers. Now the situation is different. If we try to rank programming languages to see if our skills are up-to-date, Java ends up on at the top (see TIOBE Index). C replaced Cobol, which is meant to be a better language for business domains. It is the same case with Ruby and Rails right now – they have to fight for every bit of respect.

Scalability and Performance

Here are the some of the well described common responses (Timothy M. O'Brien) by programmers of other languages (Java, in this case) when they try to convince others that Rails cannot be used to implement web apps.

• Unlike Java, it does not have enough freedom - In other words, our developers are not disciplined enough to use a scripting language.

• Rigor / Formality - Our systems are serious and require a much more rigorous approach.

• Performance - That is the core issue, which is something that Ruby (specifically Ruby on Rails) cannot afford as per standards.

• Flexibility – RoR might not be flexible enough because they cannot afford to follow the database naming conventions ActiveRecord demands. In other words we can’t follow the database standards that Rails would impose on us.

I'd conclude to this in the same manner as Maik Schmidt did:

"Ruby cannot compete in many respects with platforms such as J2EE or .NET, but it doesn't have to, and it doesn't want to. Its strengths are flexibility, maintainability and speed of development. Although the Ruby platform might not be the biggest compared to other dynamic languages, it might well be the one that's growing fastest. And, most important, it's a lot of fun!"

Let me add to it that comparing these languages would be like comparing apples and oranges – they are very different, but both have their individual values. What most people do not realize is that with some tweaking and modification, Rails applications can be configured to handle a very significant load without sacrificing performance.

Check back soon for part IV!