Okay, here I am ranting once again about Ruby. And yes, I do rant a lot about Ruby even though I like the language a lot; my beef is usually (and in this case as well) about the various implementations.
For one of my job tasks right now I have to parse some CSV file and produce a series of graphs; while any language would work just as fine to produce this kind of graphs, I wanted to use Ruby because that’s my usual language of choice, and it also provides all the needed interfaces and libraries I needed, or so I thought. Reality smacked me down hard.
First problem: the speed. I know already that Ruby processing isn’t exactly fast; luckily there’s JRuby to solve that, usually. With the exception of the startup overhead, JRuby can process data much faster, and thus would be the candidate of choice for producing some less rough cut of the data, so my first choice was to use JRuby to read and condition the input. I had, though, the bad idea of wanting to try fastercsv to read the data, which as the name suggest should be faster (given it’s going to handle over 20MB of raw data, it seemed like a good idea)… an ebuild (using ruby-ng of course) later, I discover that the testsuite of the library fails under JRuby (I guess I should report it but I’m not sure to who).
Okay, second choice: Ruby 1.9, which is faster than 1.8 in many ways, and includes fastercvs bundled in the standard library. At that point, I thought I could also draw the graphs directly in Ruby, with gruff, which works quite nicely. Unfortunately gruff requires rmagick, which is not ported to Ruby 1.9 at least in Gentoo (the ebuild is probably too complex to write supporting both with the current infastructure; maybe porting to ruby-ng works, but I’ll have to find more time to try that as well).
Finally, I’m left with Ruby 1.8 that could do what I want but I’m sure will be the slowest option out there, and I’m not sure I want to try it. I really hope that Hans and Alex can find time to help me validating the new ebuilds, so that we can actually move to use those, maybe that will give enough support for Ruby 1.9, and for JRuby, and we could finally get to have a single implementation with all the feature people are going to need (speed and library support).