The Pending Ruby/Java Co-op
CityPW
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.