Could someone explain in some easy terms why you (from my understanding) re-implement languages like this?
Could someone explain in some easy terms why you (from my understanding) re-implement languages like this?
The most frequently cited reason is to take advantage of JRuby's generally quite excellent Java interoperability. In many cases it may be the best way to introduce Ruby into an organization with a large, legacy Java codebase. Further, despite its oft-maligned reputation, Java still offers the largest number of high-quality, performant FOSS libraries of any platform. In our case, we are developing a Rails application along with a supporting Scala library simultaneously. In my experience, JRuby/Java/Scala integration is largely painless.
Further, JRuby could legitimately be considered the best Ruby implementation. It's very rare to find pure Ruby code that works on any other Ruby implementation but not JRuby. JRuby is, in general, faster than Ruby 1.9 (and in almost all cases much faster than 1.8). Further, upcoming enhancements in JDK 7 may allow some very impressive speed-ups (see http://blog.headius.com/2011/08/jruby-and-java-7-what-to-exp...).
* has a web interface: take advantage or Rails
* needs scientific computation like machine learning and such: take advantage of the java platform librariesHowever, Oracle is working on a JavaScript implementation that leverages it: http://www.wiki.jvmlangsummit.com/images/c/ce/Nashorn.pdf. See also https://github.com/dynjs/dyn.js, another incipient JavaScript implementation.
By embedding Ruby or Python within the Java Virtual Machine or the .NET CLR you start your program/library with a single process.
For instance, Ruby by default didn't have great concurrency so users ended up spawning more processes to handle amongst other things concurrency. JRuby's selling point is that you don't have to work with so many processes and you can instead rely on the battle-tested multithreading of the JVM. It opens up the chance for more bugs when using threads, but you do cut on the need to use so many processes.
Besides, scripting languages have always made it easier to string together a program for testing, managing and prototyping. Not only do you not need to spend time recompiling programs in scripting languages, but you also have more freedom regarding your code. Java for instance demands one class per file. With a scripting language, you can have as many as you want. With a scripting language you don't need a Makefile as it's easier to use just a few files to get your job done.
Now you could question the need to have so many different scripting languages. But you could also question the need to have so many different non-scripting languages as well.
An implementation of Ruby on a new platform, JVM in this case, allows new choices to be made, involves a different set of tradeoffs, etc. RAM usage, startup time, JIT features, etc -- these are all factors.
Interestingly enough, there have been quite a few attempts at removing the GIL from CPython, too: http://mail.python.org/pipermail/python-dev/2001-August/0170...
Not only that, but JRuby tends to be faster than the de facto official Ruby implementation under most high concurrency or long running process conditions.