Enterprise Ruby
Recently, James McGovern wrote about what it would take to make Ruby an Enterprise language, and as easy as it would be to be snarky and comment about certifications and bloated distributions, I thought I would take some of his suggestions that are noteworthy.
bq. Embrace JRuby: This includes surpressing Ruby functionality that will not be compatible with JRuby (e.g. Forking, etc). The Java community dealt with this early in their lifecycle when MS introduced their own spin. Ruby on a Java VM will provide the scalability that enterprise applications require.
The reasons to embrase the JRuby project are numerous, however, I’m not sure that scalability is really one of them. I’ve not seen any extensive benchmarking, but I find it difficult to imagine that JRuby is any faster than the CRuby1 interpreter. Certainly Jython was never any faster than the regular Python.
That is not, however, to say that there is no reason, namely access to huge numbers of libraries and resources. In addition, JRuby makes a good glue to get a lot of things up and running on Java, where otherwise you’d be wasting your time with the record-keeping noise of the language. It also begins to introduce dynamic concepts to a world that has largely avoided thinking outside their box.
Industry Analysts: Get a large analyst firm such as Gartner or Forrester to start providing coverage of the Ruby community at large. I suspect if you make enough noise, they will pay attention.
I doubt it. Nobody’s going to pay them. My experience with the various firms is that if you don’t pay them, they don’t care. It’s largely like politics, and the results are just as odious.
Standards and Tools: Beyond the tool itself, figure out the equivalent support for things such as Ant, JUnit and other Java utilities. The notion of configuration and release management practices is vital for enterprise
adoption.
Um, once again, Mr. McGovern manages to ruin an otherwise interesting article with blinding ignorance. First, there is Rake, which manages to have 80% of the needed functionality of Ant, without the eye-bleed inducing syntax. This is proof that XML is not useful as a DSL, and people keep trying to cram it into places it really shouldn’t be.
Second, there is Test::Unit, which, like JUnit, is derived from the same Smalltalk model. Tracking a bastard version of a good idea isn’t really that helpful. JUnit is modeled for a statically typed language. There is much more to be gained by looking to it’s real source. Additionally, Ruby is beginning to push the boundaries for behavior driven development and I hear a lot more serious discussion of the need to test behavior, rather than bits, which is something that the Java community hasn’t really latched onto yet. Where Java tries to slam it into the JUnit framework, giving yet more ill-fitting DSL nonesense, the Ruby community is refining the DSL to be more specific to the needs.
There’s all sorts of tools, such as Capistrano, and Damage Control that are beginning to address a lot of the other areas. Configuration management is really a development-methodology problem, not a language-level problem. Technology is just a tool, and without the right approach, it’s still useless.
Security: Figure out how to add in support for enterprise security and management functionality. Consider deep support for SNMP, XACML, CardSpace and SAML. Figure out ways to have mechanisms that support not only signing of code using PKI approaches but also embrace identity-based encryption.
Here’s a place that mr. McGovern starts to touch on something useful, but only manages to bounce off the point. “Deep support” is an absurd concept. Either you have a good implementation for support, or you don’t. Deep support implies integration into the language itself, which is damned foolish.
SNMP is most assuredly not security-related, and is in actuality, often the point of attack for many systems. A lot of people turn it off as a matter of course. XACML is a funny thing to talk about “security”, since it’s really just yet-another-XML-wreck, masquerading as a wanna-be DSL. Implementation of XACML, in any useful fashion, is an application-layer problem, not a language-level problem, presuming you have a passable XML parser, something that Ruby does need some work on. SAML largely falls in this same category.
CardSpace (previously InfoCard) is a Microsoft-specific approach to identity management. The Ruby world would be better served with tracking one of the more open standards, and not something Microsoft is likely to abandon at any moment, like all their other “initiatives”.
Really, Mr. McGovern, if you did more than just skim the latest white-papers and press-releases, you might understand that most of these are either vapor, not-security related, or not something that the language itself should address. Now, libraries are another world entirely, but that doesn’t even apply in most things here.
I would like to see better support of crypto in Ruby, but realistically, that’s mostly better glue and exposure of OpenSSL, and not some of this other stuff. Much of these requests feel like a buzz-word generator sourced list, rather than anything based on experience.
Environments: The world runs more than just Intel and Windows. Consider ports to other operating systems such as Z/OS
Ruby is primarily a UNIX toolset, including MacOS X, and I suspect covers 90% of the desired targets. z/OS is interesting, but it’s also an entirely separate beast. Most of my experience with Java on the z/OS platform is in Linux VMs, not in the z/OS (i.e., MVS-derived) world.
Consulting Firms: Figure out a way to get other than basement type not worth talking about small consulting firms to blog on Ruby usage. The community should put a little effort into persuading large (10K plus) firms such as Accenture, Infosys, Wipro and others on the merit of using Ruby for their clients as the small guys aren’t even on most enterprises radar and if they are, they usually are assigned to non mission-critical application development
Who is to say they aren’t doing so? Just because they don’t talk about it doesn’t mean they don’t use it. The firm I work for does work in Ruby for money, and is larger than any of those firms. We also do work in Smalltalk, Lisp, C, C++, Java, and just about anything else that exists in the world. Just because we don’t talk about it (and we do, indirectly) doesn’t mean we don’t find it interesting. Few people talked about Python for many years, when it was safely ensconced in NASA and other places in mission-critical places. Most “consulting firms” are best at the late-adopter phase and after. This makes sense from a business perspective.
Media Relations: The Ruby community needs a better face to media relations than David. Find someone with a background in IT across many different sizes of companies, business models, etc and turn them into the face. This person’s first task after taking on this role should immediately ask the likes of Doc Searls, Jon Udell, Richard Stallman and others who already have capital in terms of enterprise mindshare to also start blogging on the merits of Ruby
You can’t be serious by actually mentioning RMS as a “suitable” spokesperson. That shows so much ignorance that I can’t begin to quantify it. Personality and licensing disagreement would eliminate that, but then you’d know that if you had any experience in this area.
Conferences: The Ruby community needs to stop solely speaking on Ruby at developer-oriented venues and start speaking in business-oriented venues. Software Development in the US is simply going offshore and you will be speaking to a shrinking marketshare. Instead focus on making sure your stories are being heard by CIOs and enterprise architects
Oy, I don’t even know how to respond to that. So many assumptions that it really is only accurate in its own psychological universal echo-chamber.
It’s unfortunate that once again, Mr. McGovern allows a perfectly good idea to be derailed by ignorance and inexperience. That isn’t to say “we” shouldn’t be thinking about this, but it’s important to keep things in perspective.
1 Stolen from the Python world. CPython is the original C implementation.
This entry was posted at 10:16 pm on 11 November 2006 and is filed under Ruby. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
Oh, no disagreement that the current interpreter is painful. Ruby succeeds in-spite of its hobbled runtime. However, most larger Ruby applications tend to do a lot of metaprogramming, and that is something that, in my experience, is unbelievably painful and slow on the JVM, so I don’t know that it’d be that big a performance increase.
Finally, I find that when someone in the “enterprise” complains about performance, it’s even more laughable than when most “dot-commers” complain. With the exception of perhaps 10-20 companies, no internal-facing application will ever be even half as slammed as a moderately successful Internet organization. Performance just isn’t the primary concern for most people, it’s just the red herring everyone loves.
Nice article!
I don’t really know if I agree because I don’t know very much about the Java world, but I find it very interesting.
Just one comment: when you’re talking about scalability and you say “I’ve not seen any extensive benchmarking, but I find it difficult to imagine that JRuby is any faster than the CRuby1 interpreter. Certainly Jython was never any faster than the regular Python.”, I think you’re missing the point. Scalability is not about performance. JRuby could be twice as slower than CRuby and still win in scalability (or viceversa).
Scalability is about the ability of a system to grow up, and is independent of performance. It is about, for example, the difficult to make a system run in a fairly large number of boxes. Ruby (I mean Rails in my case) manages this well, but I don’t know about Java.
Ruby’s (I mean CRuby’s; I did’n try JRuby) performance is horrible. But that doesn’t matter as long as:
1) It’s scalable. It’s easy to, say, double the number of servers running yout app.
2) Increases developer’s performance.
A new server is cheaper than a new developer. Double servers + Half developers + Half time = Nice project!
McGovern challenged the community to find solutions to perspectives which cannot be solved by a single person responding solely to him. Regardless if you like it or not, there are more of him than you which I guess you missed the entire point.
Mr. McGovern didn’t “challenge the community,” instead he made wild statements that are unsubstantiated by fact. While it may be true that wild-ass speculation is more common than well-reasoned thought, it hardly makes it valuable.
If Mr. McGovern were truly trying to improve anything, other than his own visibility and traffic, he might consider spending a modicum of time understanding the technology he spouts off about. When you make wild statements like “Ruby needs a version of JUnit,” which are demonstrably false by anyone with 12 neurons and access to Google, it’s really difficult to proffer more than ridicule as a response.
re: Scalability
While scalability means many things to many people, it is often the label attached to the belief that something needs to be “bigger,” or perhaps just “faster.” Ruby, as demonstrated by many applications, contains the bits and pieces needed to solve 90% of problems. Perhaps Java can be used to solve an additional 2-3%, but at what cost?
People often misconstrue complexity for “scalability,” and the inverse is actually true. Complexity is the hubris of most architectures and is where they fail miserably. This is an unfortunate situation when many EAs are paid for their complexity. True insight, however, is in the reduction, not addition, of complexity.
A new server is only cheaper than a new developer if you only consider purchase cost and not all the licenses that go on top of it. Also, developers are cheaper if you outsource to India and quality is ten times better than in US.
[...] Sometimes, I do wonder whether my interpretation of the English language parallels the commonly-accepted version, and today is just such a time. Earlier, I wrote about some comments James McGovern made, and now Mr. McGovern has responded—unfortunately misrepresenting what I said, and conveniently leaving out bits. Let’s tear it does, as usual. [...]
Responses are currently closed, but you can trackback from your own site.
The current standard Ruby interpreter is quite slow as it just builds an AST from the source and walks it to run the code. I expect almost any other approach, done by someone with experience, would be noticeably better. YARV is the current leading project in this area.