What follows started out as a single bullet point from a list of predictions for 2007. It somehow went awry. As such, you would do well to consider this piece with roughly the same amount of seriousness as would be given to any other tech prediction article.

A couple of years ago I was excited about dynamic languages on the JVM and what it could mean for web developers. Then I wasn’t. Now I am again. I’ve been completely clean of Java for almost two years now but I have a feeling that might change in 2007 (probably late 2007).

Java will Eventually Not Suck

There’s basically three things that need to occur before Java gets to go back in the toolbox:

  1. The mainline JVM must be available – the way I want it. The hardest part of this was done when Java went GPL and makes everything that follows possible.

  2. The quantity of Java packages must go up. I want a huge inventory of libraries packaged on all popular Linux and BSD packaging systems. I’m mostly interested in FreeBSD, which already includes 148 Java related ports in the main repository, but I need to know packages exist on all major Linux distributions as well.

  3. The quality of Java packages must go up. By quality I mean packages should be individually well maintained, patched appropriately for the intended system, and updated with little lag behind upstream. Quality is a function of eyeballs. #1 and #2 will result in an increase of eyeballs and thus an eventual increase in quality. QED

  4. Better JVM startup time. This may be fixed already, I’m not sure. If it isn’t, it will be once #1, #2, and #3 are in effect.

  5. JRuby running under rough performance and feature parity with CRuby.

Once these things are settled, Java becomes a serious option for me and people like me, whether we know it or not.

Java: A Better C

All Java has to do is be better than C at some of the things C does now. Java will, in effect, become the new C with a small but critical difference. Before we get into what that difference is, let’s take a look at a few of the most important things C does for web developers today:

  • The HTTP/web server. Must be fast, fast, fast – silly fast. Right now this is httpd, lighttpd, nginx, and Mongrel. All C.

  • The language interpreter: python, ruby, perl, php, etc. (I suppose java should be in that list as well :)

  • Lower level support libraries: libxml2, openssl, ImageMagik, cairo, glib, yaml, RDBMS client libraries (psql, mysql), gzip, bzip, termios, etc.

  • Situations that require better performance than is easily had in a higher level language: extension libraries, basically.

You didn’t know how much you loved C, did you?

C is portable, fast, has lots of quality libraries, good tool support, and is Freely available. Java is portable in theory, fast enough, has lots of quality libraries, excellent tool support, and is about to become truly available.

At this point, the pragmatic developer should be asking, what makes Java so much better than C that I should consider using it instead when I’m satisfied with what I have today? The answer is quite simple: malloc(3) and free(3), and more specifically, Java’s lack thereof.

You can take Java’s crippled OO foundation, enterprise scalability, vendor supported JEE containers and just throw it all out the window: I don’t care. Memory management is the reason to consider using Java over C right now.

Ruby: Just Because

Ruby is but one of many extremely productive and well designed high level languages: Python, Smalltalk, (Good) Perl, Scheme, Common Lisp, Groovy, Nice, etc. All amazing languages when you care about expressing logic to humans and, incidentally, to machines*.

If classes have a class, I’ll take it over Java. So why Ruby?

  • It hasn’t failed yet. I mean, Jython’s been around for a long time, seems to have lost steam, and the original author was hired by Microsoft for his work on IronPython. While I wouldn’t go so far as to call this failure, the momentum needed to build a strong community around the JVM seems to have waned.

  • Many other languages have already been smeared as kiddy scripting environments by Sun and the tech press.

  • The Perl guys are busy on their own VM.

  • There’s already interest in improving Ruby’s running environment in the Ruby community. The C based Ruby interpreter doesn’t seem to have the same level of prestige as, say, CPython or perl. It’s widely considered one of the slower dynamic language interpreters. Work on a new VM was recently merged to Ruby’s trunk but is not yet stable and won’t be for some time.

  • PHP doesn’t need the JVM: as far as I can tell, PHP is pretty much tied to C for all eternity. I’m not saying that’s a bad thing but the C under-pinnings are so clearly visible in the higher level language that putting the thing on Java almost seems like an insult.

  • Ruby is cool right now. I don’t pretend to understand the mechanics of cool but Ruby is it – for the time being, anyway. Whether that makes sense or not is irrelevant; with hype comes real and tangible benefits.

Now, as much as I like Ruby, I don’t think there’s anything insanely spectacular about the language that makes it better suited for a coup d'état on the JVM than many other languages. It just seems to be in the right place at the right time.

The other reason I’m focusing on Ruby is that I’m biased, lazy, selfish, and trying to create a bit of hype here. I’ve been using Ruby heavily for almost a year now and, as much as I hate to admit it, I’m beginning to hit a performance wall in some very specific cases. In addition, a few Java libraries have caught my eye whose Ruby or (C with Ruby bindings) analogs are considerably less developed.

I want to be clear that performance is not a problem across the board for me in Ruby. Quite the contrary, in fact. Performance has been good enough in all but a few corners of development. I’m also not talking about the ability to scale or anything that can be fixed with more hardware. I’m talking about stuff like image manipulation (graphing specifically), PDF generation, and flat file parsing. In these places, I could really use orders of magnitude increases in raw performance over what I can reasonably expect from Ruby today.

Solving the performance problem has meant dropping down into C, which isn’t all that bad but I’d personally be more comfortable dropping down into Java.

How this plays out in 2007

In Java land, people start taking Ruby seriously as an alternative to The Java Language on the JVM in a way that Jython, Groovy, and other dynlangs never accomplished. Not as a “scripting” or “glue” language but as a first class, general purpose programming language. A comfortable majority of components will still be written in Java for performance and broad reuse but Ruby will come in from the top and begin to steal away much of the application level logic on new projects – basically anything where readability and maintainability are more important than performance and reuse.

Ruby’s impact on the Java community will be almost entirely due to JRuby reaching increasing levels of bad-assedness. That is to say, Ruby’s adoption by Java heads on Java projects won’t have as much to do with the GPL and better packaging support as it does with the virtues of the Ruby language and the JRuby interpreter.

Suns increased financial support for, and clueful positioning of, the Ruby language in the Java ecosystem will also be critical. There’s all kinds of problems with this part, of course. Mentioning “Sun” and “clueful” in the same sentence generally requires a negation but there’s cause to believe that might be changing. A boy can dream, anyway.

While all this is playing out with the Java folks, the JVM will begin to be taken seriously as an alternative to CRuby in the Ruby community. Unlike in the Java world, this has less to do with JRuby and more to do with Java going GPL and the ready availability of the mainline JVM on Linux and BSD. You will begin to hear reports of Rails running on the JVM in both development and production environments with very little disruption to existing code bases. This will be followed by blog post after blog post extolling the virtues of being able to drop down into Java for performance critical pieces of code and how nifty JFreeChart is.

By the end of 2007, much of the Ruby web development community will consider the JVM to be a viable runtime environment. In Java land, Ruby on the JVM will be a growing sensation but it will take another year (2008) before Ruby is considered a peer to The Java Language.

On the other hand…

Things could be horribly different. Sun could marginalize Ruby the same way it has marginalized every other language that’s tried to run on the JVM in the past. JRuby could poop out before reaching a satisfactory level of stability and performance (see comments). The Ruby community could reject Java because of its historically poor reputation among hackers. The larger Java community could reject Ruby as a kiddy language.

One thing’s for sure: we’ll be hearing a lot about Ruby and Java in 2007.

Comments

  1. I totally agree. But I think Sun wil loose this battle to MS who are more agressive on this issue and are promoting something like IronPython far better. I mean just take the name..

    — fad on Saturday, December 30, 2006 at 12:39 PM #

  2. Try Ocaml

    — Harry on Saturday, December 30, 2006 at 08:31 PM #

  3. Industry analysts have more power to determine the fate of Ruby than MS and Sun combined. You have to ask what Gartner thinks of it..

    — James on Monday, January 01, 2007 at 09:52 AM #

  4. The HTTP/web server. Must be fast, fast, fast – silly fast. Right now this is httpd, lighttpd, nginx, and Mongrel. All C.

    Not Mongrel. Mongrel’s fast, but it’s not written in C. It’s written in Ruby, with some of the HTTP parsing done in C.

    — Peter Cooper on Monday, January 01, 2007 at 10:20 AM #

  5. What about JavaScript?

    — Jay Huff on Monday, January 01, 2007 at 10:32 AM #

  6. About readability/maintainability: what astonishes me is that it is a well known fact to anyone developing in java that the pluses of the language are its simplicity and maintainability. I have been working in java since 1998, and have never felt the urge to move to a sexier language: not that I can’t see ruby’s charme, but I’m simply too fond of the fact that I can grab almost any java program written by any (serious) java developer, and understand how it works in a matter of minutes (and a number of ctrl-b / ctrl-alt-b in intellij IDEA). The paradox of it all is that the more the language changes trying to appeal the crowds (see the old generics debate,see the recent closures one), the riskier seems to become its position in the “readability/maintainability” space: but I really don’t buy the fact that ruby is more readable/maintainable. It may be more “productive”, in a number of senses, but I strongly doubt its advantages are in terms of readability and – most of all – long term maintainability (give me SERIOUS refactoring/searching tool support and I’ll reconsider this).

    — Davide Baroncelli on Monday, January 01, 2007 at 12:29 PM #

  7. Peter said:

    Not Mongrel. Mongrel’s fast, but it’s not written in C. It’s written in Ruby, with some of the HTTP parsing done in C.

    I may be wrong about this but I’ve always assumed the C based parser was what set Mongrel apart from other options. Both because it’s generated from the formal protocol grammar (safety/correctness) and because of the huge performance win. Was performance not a big deal? If you could generate a Ruby based parser from the grammar, would it be adequate?

    The point being: C is an important aspect of Mongrel’s story.

    Jay said:

    What about JavaScript?

    Ahh, the dark horse. There’s a lot that could be said about JavaScript on the JVM as well but Ruby’s historic use as a server side, systems language as opposed to a browser side, scripting language gives it a bit of an edge, IMO. There’s a lot of other things to consider here.

    — Ryan Tomayko on Tuesday, January 02, 2007 at 04:11 AM #

  8. Thanks very much for the kind words. And I agree, it seems that Sun has really woken up and embraced that which the rest of the world has loved forever: dynamic languages.

    And as far as the JRuby effort “pooping out”, well, I’ll be damned if that’s going to happen. I’ve poured the past two years of my spare time and the past 3.5 months of my fulltime into making this thing go, and you better believe we’ve got some serious momentum. JRuby will succeed, or I’ll die trying.

    Thanks for the great post and the great thoughts about Ruby/Java cooperation.

    — Charles Oliver Nutter on Tuesday, January 02, 2007 at 09:39 AM #

  9. Davide said:

    I’m simply too fond of the fact that I can grab almost any java program written by any (serious) java developer, and understand how it works in a matter of minutes …

    I’ve thought about this quite a bit in the past few months. There’s an interesting article on complexity and dynamic languages that puts forth a theory on productivity curves for Java vs. JavaScript:

    I would argue that less skilled developers in a team environment are actually destructive — i.e. they cause more work for other developers. I would further argue that the productivity curve for a language like Javascript is different than that for a statically typed language like Java. I have no data to back this up, but my impression is that the Java skill vs productivity plot is closer to linear, while the Javascript plot is more like a second order polynomial.

    The graph is here. Java is blue, JavaScript is purple. I think the general concept may apply not only to productivity but also to readability. This may actually be the best argument out there for why uptake of dynamic languages hasn’t been even more accelerated: people lose the ability to read dynamic languages very quickly once you pass over into the less proficient half of programmers where static languages take much less of a hit.

    This is all just theory, of course, but it answers some tough questions in a way that seems to be consistent.

    — Ryan Tomayko on Tuesday, January 02, 2007 at 03:30 PM #

  10. [Argh – after saying yesterday I was getting interesting in Java again. How did I miss this post? Happy new year Ryan]

    “people lose the ability to read dynamic languages very quickly once you pass over into the less proficient half of programmers where static languages take much less of a hit.”

    I think the graph is notionally ok, but not substantatively. And it’s missing the impact of frameworks, libraries and the volume of code you have to keep in mind. If you look at the code for say, these – Zope2, Rails, WebWork2 – it’s clear to me that WebWork2 is easiest to comprehend, then Rails, then Zope2. The comprehension issue for me tends to come down to how much reflection and dynamic featuring is being used – Zope2 is almost overwhelming in that regard, Rails is fine. I’d like to think there’s more to the difference than 7 years development.

    — Bill de hOra on Wednesday, January 03, 2007 at 08:17 AM #

  11. I agree.Perhaps Sun will be losed in this battle to Microsoft.But OpenSource is only hope to beat MS.

    — Shawn on Thursday, January 25, 2007 at 01:43 AM #

  12. I agree with the overall direction of this article.

    The “On the other hand” scenario could include the possibility of the rise of (or Sun’s embracement of) Scala – a Ruby-like language that compiles and runs on the JVM ab-initio.

    — Vish K on Monday, March 05, 2007 at 09:26 AM #

  13. MS will beat sun. They always do. Sun should have opened the JVM years ago, but they got greedy and they lost. Now MS developed a better one. I believe we will see a better .NET VM in 2008 than a JRuby VM. Hopefully we will see a good compiler on Linux to support it… But I’m not holding my breath. I was programming Java in 96. Its been so long… Ruby is just an order of magnitude faster to develop code in than Java. I’d like to be able to drop back to Java instead of C for performance, but seriously, Java isn’t all that fast either.. and its much more difficult to even get hello world running in an EJB environment, not to mention the cost of servers you need to run the thing… That a lot different than when I was writing CGI in ~92. That was fast :) and easier than EJB. Ruby has its place..I’d love to see it run on the JVM with same easy of setup it has now. Hopefully this can happen in 2008.

    — Brian on Thursday, February 28, 2008 at 07:16 AM #