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, 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.
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.
 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