Geek Smithology

September 18, 2006

The State of Enterprise Ruby

Filed under: Craft of Dev,Ruby by Nathan @ 8:48 pm

I have been to the mountain! Having spent three days in the cloister, intensely meditating the Zen at the core of the Enterprise Ruby scene, I have clearer insight into the current state of affairs. Using the simplest terms, in the most convenient definitions, here are the enterprise concerns we attempted to allay…


When contemplating the appropriate context for scalability, let me remind you that the word “big” is both too subjective and too narrow. Think arbitrarily sizable without significant development overhead. Ruby is good at this. So is Java. So is Perl. So is any system with the appropriate architecture. I worked on a system with tens of thousands of users (several hundred simultaneous) that required no client server stickiness whatsoever – merely a round-robin load-balanced cluster of JBoss dragoons. If the load got heavy, we’d just add more heat, and the system would chew through simultaneous connection like Sauron’s hammer. Ignoring all other aspects of this system, Ruby could certainly have handled that same load. ‘nuff said.


Ruby is a smorgasbord of tools that increase your flexibility: dynamic typing, blocks, closures, mixins, and that’s just the list of things that are easy to understand. You simply cannot beat Ruby for flexibility, and the maxim “Thou shalt trade CPU cycles for developer cycles” makes its most sense in this area. Not quite a year ago, during dinner with Dave Thomas, he mentioned that people were doing enterprise development with Ruby, using it as glue between big iron systems. This I get. You want a quick cron to check a property in LDAP and then use a Web Service to drop a message into a queue? Save yourself some hell and use Ruby. Have a lot of legacy code in another scripting language (like, say, Perl…not that I have any experience with that or anything) and you need to start talking to MOM components, the only thing sillier than not using Ruby would be to put nipples on the Batman suit. And you know that worked out.


Here, we’re thinking enterprise reliability (like, 1 + 1 always equals 2, and if it doesn’t, your software is the last thing you’ll care about), not script reliability (like “M. Night Shyamalan will always make good movies, and if he makes the Village, well let’s just not bother with Lady in the Water.”) A good example is Rinda. You can share distributed tuplespaces until the cows come home[1], or until the machine crashes, whichever comes first. I for one don’t want to restrict the lifetime of my messaging infrastructure to the MTBF of that Dell server my client bought because it was “cost effective.” You want guaranteed delivery? You want durable messaging? Then consult your friendly neighborhood JMS implementation (there are some good open source MQ systems) and let Ruby talk to it.

If your server infrastructure is running Ruby, be aware of the performance (or lack thereof.) It doesn’t have native threads and isn’t compiled. I know, I know, 37 signals is running a gazillion hits through Rails, but if you’re doing heavy back end processing (say, image processing or time critical data analysis for reporting) you’ll want to trust something a little more specialized, compiled, and up to the task. However, keep in mind the words of Dave Thomas:

I wouldn’t do stuff that required high performance in Ruby, but I wouldn’t do it in Java either.

There was another reliability hit: it was harder to get some piece of the puzzle working than getting Paris Hilton and Nicole Richie speaking again. LDAP took a Conan-at-the-wheel-of-pain level of effort to get running under Windows (and we gave up on the pipe dream of actually building it and just Googled some pre-built dlls), and we never did get the JRuby web server to work.

Finally, damning as all the rest, there are no distributed transactions. You need to make sure you grab something from the queue, write to the database, and drop a new message in a single transaction? Ruby won’t do that. So while this stuff is coming along for internal tools and admin scripting, you can’t trust mission critical back ends to Ruby.


One thing I have to make crystal clear is that I am writing this for people who are wondering about Ruby’s suitability as an enterprise platform. This is NOT a rebuttal to the Ruby community, because they are so damn pragmatic, they wouldn’t endorse Ruby as a back end platform. I cannot stress this enough: Stuart and Justin never sold Ruby as anything other than a very convenient tool. Nobody is saying it’s a replacement for Java, just a good companion. Justin has a very good blog post about this exact subject.


There was not much said about security, because Ruby doesn’t have a lot of support that you don’t code yourself. Concepts from the .NET and Java worlds like Declarative Role Based security or Authenticated Principle objects just don’t exist. I’m not saying that those languages have the problem licked, but I am saying that they make it easier to track authenticated users (at a thread level in the case of .NET). That’s a big deal when we’re having the debate about how best to spend developer cycles.


Ruby ostensibly supports Unicode, but most of its libraries do not. And unlike Java and .NET, there is no support for locales (cultures, for the .NET folk) and bundled resources. Of course, in Java and .NET, most developers don’t pay any attention to character encoding and end up painting themselves into the exact same corners. But as someone who was attempting to run a dynamically multilingual website, this is a tough pill to swallow. Oh, and I have to say this: extended ASCII is NOT internationalization.

In Closing…

So there it is. I know I’ve painted a grim picture, but that is only because I was earnestly hoping that Ruby was more mature. I am a staunch support of Ruby and genuinely love programming in the language. I’m buoyed by the progress made so far, especially compared to other scripting languages. And one can’t help but be optimistic that the rich communities of great minds doing significant work in Ruby will eventually elevate it to a higher plane.

The real takeaway is that if you truly believe in using the best tool for the job, then you will be using Ruby at some point in the future.

[1] As a resident of Calgary, dear reader, there are two things I can promise: The postman always rings twice, and the cows always come home

4 responses to “The State of Enterprise Ruby”

  1. What sort of problems did you have getting JRuby running in a web-server mode? I know that Mongrel doesn’t work yet, but WEBrick should work fine for most cases. What were you trying to have JRuby do?

  2. aakin says:

    so from the things you say i rather not use ruby ;). i want an expressive secure language, maybe for small scripts ruby is fine tough. And do not put vague quotes like this: “I wouldn’t do stuff that required high performance in Ruby, but I wouldn’t do it in Java either.” when java is 100 times faster then ruby, it is a hard thing to swallow.

  3. Francis Cianfrocca says:

    There’s a lot to say about your points here, but I’ll stick to a side-note. LDAP in Ruby (especially on Windows) is now a lot easier. Look at the Net::LDAP library, which is in pure Ruby and doesn’t require a compiler or DLLs.

  4. Nathan says:

    aakin: I don’t know where you heard that Java is 100 times faster than Ruby. I don’t even think that one could manipulate a completely bogus synthetic benchmark and still make that claim, and as a legitimate argument, it’s completely specious. But yes, I would say that the average programmer would rather not user Ruby.

    And the quote is not vague – if I had to build a system for which performance was the primary concern, I would certainly not use Java. Note, I’m not talking about Enterprise applications with web services, data access, distributed operation, and security concerns with an eye to extension and flexibility. I wouldn’t want to use an OS written in Java. I wouldn’t want my graphics driver to be written in Java. So on and so forth.

    Variety is the spice of life, let us use the best tools in the best way we know how.

Leave a Reply

Your email address will not be published. Required fields are marked *


Powered by WordPress