Summary
Zed Shaw, creator of the Mongrel HTTP daemon, explains how the decision to use any language, including Ruby, depends on the appropriateness to task and the amount of yak shaving necessary. He lists 7 plusses and 6 minuses of using Ruby for enterprise computing tasks.
Advertisement
CIO magazine has been continuing its series on the appropriateness of languages to certain enterprise task with an article by Zed Shaw, focusing on Ruby, in You Used Ruby to Write WHAT?!.
Shaw is well-known in the Ruby community as the creator of Mongrel, an Apache HTTP front-end and the most popular tool used to deploy Rails applications. In the interview, Shaw lists 7 pros and 6 cons in using Ruby in the enterprise.
Shaw starts by saying that multi-language virtual machines and the general availability of high-quality libraries in various languages make language choice an increasingly non-technical decision for many projects:
When considering in what language to write your next project, remember that your primary goal is not arbitrary technical concerns such as performance or scalability, but rather whether you can maintain a solid stable of smart developers long enough to make the project successful...
This has probably been the most overlooked "feature" of Ruby by most people advocating it: Young kids actually want to work for you if you build software in Ruby or Python, Erlang, Haskell or Lisp... Ruby and friends are the languages they learned for fun: to play around with interesting ideas and to use when they hang out with friends online.
Focusing on Ruby, Shaw lists 7 pros and 6 cons of using Ruby for enterprise computing tasks. Since Ruby's plusses are often elaborated, Shaw's list of Ruby's negatives for enterprise computing are perhaps the most interesting part of the article:
Large data crunching
It's sad to say, but Ruby (all versions worth using in production, and even Ruby 1.9) suffer from huge problems with large-scale garbage collection, I/O processing and thread operations...
Image manipulation
I don't really think many languages are great at image manipulation, but Ruby is particularly bad at it. The primary libraries available are based on Image Magick, which is slow, bloated and takes forever to install on many systems... Ruby talks to Image Magick through RMagick, which suffers from memory leaks, spawns external processes silently for many operations and is difficult to install (unless your computer is nearly exactly the same as the author's). Other libraries are no better...
Heavy math or computation
Ruby's computation performance is limited compared to that of other languages. Many times a programmer has to either rewrite math-related sections in C or Java—or ask a Ruby guru to help him optimize the initial code several times. Usually these "deep voodoo" optimizations don't survive the next minor version of the Ruby interpreter and need to be rewritten...
New language development.
While Ruby can build very nice DSLs, any errors in the DSL source aren't specified in that language, but instead, as Ruby errors. That's confusing. If your intention is to provide a language that a financial analyst can use to do her day job, then the error "undefined local variable 'var' for main:Object" is not helpful. In this case, you'd need a real parser with actual error checking and a better syntax that's not dependent on Ruby's—and this is where Ruby falls flat in practice.
E-mail processing.
Just about every other language has better e-mail processing capabilities than does Ruby. The libraries available to Ruby are half-implemented, have odd bugs and incompatibilities, are slow, bloated, and generally just don't compare to what is available...
Server protocols.
Ruby's problems with I/O processing means that writing truly scalable servers is a waste of time. Most of the people I know doing server work in Ruby eventually give up and either use a mix of Ruby and C or they switch to another language entirely...
I would prototype a new protocol with Ruby for its implementation speed; but if I had to make that prototype handle more than a few hundred users doing a few operations per second, I'd switch languages immediately. There are libraries that attempt to solve this problem in Ruby, but most of them are still constrained by Ruby's IO event loop...
What do you think of Shaw's comments on using Ruby for enterprise computing tasks?
Zed's article is perceptive, fair and evenhanded. I think he is particularly on point regarding the strategic advantages of choosing a language that smart young developers want to use.
I can remember the turbulence when attempting to use Java instead of C++ 8 or 10 years ago. It is the classic fight between early adopters and the late majority (conservatives)
It's important to remember the golden rule of technology adoption curves The innovators, early adopters, early majority (pragmatists) and the traditionalists usually know their own position on the Technology Adoption curve. The Late Majority(Conservatives) invariably believe they are part of the Early Majority.
My opinion is that if a large enterprise doesn't already have a pilot project evaluating Ruby they have missed the boat.
> My opinion is that if a large enterprise doesn't already > have a pilot project evaluating Ruby they have missed the > boat.
Is there going to be a point where they will no longer be able to adopt it? My general rule of thumb with acquiring technology is that it's better to wait if you can. It pretty much always gets better and cheaper.
I would say that I benefited a bit by not adopting Java in the 1.0 or 1.1 phase. A lot of the code (and coders) that used those versions use bad approaches because of what was available at that time.
I'd like to understand your perspective on this. I see value in early adoption for a developer but I'm not sure I see what the value is in the enterprise.
I was tempted to answer, "Yes, there are only 100k tickets to the Ruby programmer ball"
You are asking a question worthy of a PhD. There are examples of successful enterprises that <b>primarily</b> work at each stage of the technology adoption curve.
My point was based on my own experience working in financial institutions, companies that generally fall in the late majority/conservative group. In that situation, there is tremendous value in evaluating new technology early with a pilot project, and it is because of the very risks and costs that you describe. My observation with C++, and again with Java, and then .NET is that early pilot projects are inevitably small and cheap. The companies that didn't do this were the same companies whose first J2EE projects were 100 person hayrides to hell.
New technology trends start small, then, if they are taking off, become a flood. One part of this flood is the desire for resume credibility by some developers. Another part is managers who want to be able to boast, "yes of course we're doing agile too." Those desires can be better managed with real experience.
Now I am talking about the conservative middle. There are also a minority of firms who can leverage new technology for competitive value and outperform their peer. Their minority status doesn't make them any less enterprises.
Of course, just like we can't all be above average drivers, all firms can't be pragmatic early majority firms.
Perhaps you are really talking about early evaluation and not early adoption and I made a leap that you did not imply. My statement above about waiting if you can was probably not completely clear. I tend to be a little conservative in these matters. Unless I can clearly articulate the value of adopting a new technology, I'm probably not going to. But I am very much in favor of pilot projects. In fact, if more companies did that instead of jumping right in it would be a good thing. Not just for evaluating tools but also in avoiding mistakes in the early stages of adoption.
> Zed's article is perceptive, fair and evenhanded.
It's not as perceptive, fair and evenhanded as you might think, especially when you consider his recent "conversion" to Python. Christopher Dicely summarizes some them nicely at:
A couple of the follow up posts are also worth reading.
The one that jumped out at me was the comment about Rails being ill suited for Content Management Systems. First, several CMS's have been written using Rails. Second, whether or not a CMS is good/successful has nothing to do with the framework, but entirely hinges on the design and the designer. Third, Ruby != Rails.
I am not a Ruby programmer, but does Ruby have a messaging service (like an equivalent of JMS) or the ability to connect to a messaging server like MQ Series etc? I can't imagine building enterprise systems without a messaging service, remote method invocation, management beans (like JMX), access policy management etc.
Enterprise is a loaded word, when used as an adjective to modify systems, applications or software. It's meaning seems to range from " used within an enterprise", "capable and robust enough to be used in an enterprise (read serious) and thus important", "technology that is purchased at the whole enterprise level, typically on the golf course or in the boardroom, often leading to shelfware"
> I am not a Ruby programmer, but does Ruby have a messaging > service (like an equivalent of JMS) or the ability to > connect to a messaging server like MQ Series etc? I can't > imagine building enterprise systems without a messaging > service, remote method invocation, management beans (like > JMX), access policy management etc.
JMS is a standard API implemented by commercial products. You can use any JMS product from Ruby. The easiest way is to run your Ruby code with JRuby and directly access the API.
I can't imagine choosing to use JMX if I had Ruby. It really isn't one the better JCP standards. Implementing a management interface using Rails or Camping is much easier, simpler than with JMX.
The best way to see how Ruby might help you is to try it on a small, low value project.
Previous Topic
