Pure Ruby

The contrast between the Java and Ruby communities approach to external libraries is interesting.

In Java, calling executables programs is hard (check out the amount of code it takes to process the input and output). Wrapping a C library is also difficult. You've got to do lots of futzing with the Java Native Interface.

Then Sun came up with the 100% Pure Java marketing campaign to promote writing applications without resorting to native code or calling external programs. This ensured maximum portability for Java applications. There is a lot of dissension and a number of spectacular failures (like Netscape's "Javagator" browser) but being 100% Pure Java is still highly regarded in the Java community, as a quick search will show. Look at the number of open source projects that come up, touting their 100% Pure Java status.

Between the difficulty of calling non-Java programs and the cultural bias against doing it, there is not a lot of this going on. That means there are things that either were re-implemented in Java, don't exist, or aren't considered.

Meanwhile, in Ruby (and Perl and Python -- the "glue" languages) the use of C extensions and calling off to external programs is widespread. Sure, a "Pure Ruby" API may be preferred if it exists, but it's not uncommon for performance bottlenecks to be re-written in C, or for Ruby libraries to wrap C libraries with a Ruby-esque interface.

This does have some problems. Not all C libraries are available on all platforms. Some scripts and libraries only work on Linux and other Unix-like operating systems. A solution that only works on most platforms would be unacceptable to many Java programmers. But it does get Ruby most of the way there, and it brings a huge advantage: Ruby can use much of the existing C libraries (or even Java, with GCJ).