Nardol

I’ve been silent in this blog last few days, but that has an explanation: I’ve been trying to make JRuby 1.1.4 work with one of my scripts.

The problem is that after having done all the tweaks I can imagine, I still can’t get enough performance with Ruby 1.8.7 (latest etch-backports). Our client will not allow Ruby 1.9 in the server (what is really a pity, for the performance boost I had with Ruby 1.9 is awesome!), but it already have Java6… So the only option I have left is trying JRuby beast.

Since our script deals with system stuff, it uses syslog a lot, and that is where the main problem seems to be. Syslog support is new in JRuby, has had some implementation problems, and sure are not something to rely on right now… so I dropped it from the script, and it run! Twice as fast (not as good as Ruby 1.9, though)!

There are some other problems with this script and JRuby, more important ones being (1) at_exit doesn’t work; and (2) errors are not easy to backtrace (when JRuby fails it seems to mess up with the backtrace stack), but not preventing it to work…

So… with the increased performance of JRuby, and after fixing those minor glitches, I was still left with the syslog problem… Until I investigate some final solution (I think I’ll have to use some Java native syslog library – given such a thing exist), I’ve split the script in “performance-boost needing” and “syslog-needing” parts; the first is using JRuby, and the second, Ruby 1.8.7… They communicate using sockets (I know… ugly… I would like to use DRuby, but I would not introduce another point of failure in an already messy situation) and the overall performance was brought to a satisfactory level.

So far, it’s been interesting to study the issue… Mainly because I haven’t used JRuby since it’s early versions, and it has improved a lot. But also because I read a lot about the future of Ruby (bytecode compilation, YARV and so on), and it made me even happier with my primary-do-it-all programming language.

Now I’ll try to compile java bytecode generated by JRuby into a native binary with GCJ :-D. Let’s see if that is do-able…

Updated 2008-09-24 18:03:00: As you can see in the comments, syslog actually works. I figured this out this morning, but JRuby Subversion already had a patch. Anyway, I submitted another bug I found.

I’ve just tested the improvements in the performance of Javascript in Firefox 3 and WOW! Javascript in FF3 is really fast. While googling about it I just ran across a recent interview with Brendan Eich about the future of Javascript and I got excited about two things about this future.

First was what we already have, still in the beginning, but with a lot of potential: HotRuby. Really interesting to script a webpage in Ruby (which is my favorite language) and, while it’s not embedded the way Javascript is, it gets “compiled” in the server side with YARV (the new bytecode compiler for the next version of Ruby, 1.9), and then served to the browser in the form of JSON objects, so it can be interpreted by the Javascript engine in it. All this is transparent and work with XMLHttpRequest. It’s not a coincidence that Eich mentions it as being a form of ARAX (changing the J in AJAX for R – from Ruby).

I already do a lot of coding in Ruby… not having to deal with Javascript anymore is surely a plus. ITOH, Eich is talking about improvements in Javascript that would render it as a real programming language… Maybe coding in it would not be so painful anymore by then ;-)

The whole interview have to do with this Project Tamarin, a “high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification” [ ECMAScript 4 is the same thing as Javascript 2 ] by the Mozilla developers. And this is the second thing I got excited for: they’ve planned to glue IronRuby (Ruby compiler for argh! .NET) to it via IronMonkey.

So… exciting news! Either via Tamarin or via HotRuby, we’ll get Ruby browser scripting. My “free mind” tends to favor HotRuby instead of IronRuby/IronMonkey/Tamarin… But in the end what matters is that all those people now cursed by Javascript will finally have a taste of what a real programming language feels like.. Who knows! They might even like it ;-D