sigh I wish I could get excited about MRI releases. It's one of the most disappointing parts of using Ruby for my daily grind. The sluggish pace of innovation is sometimes demoralizing. Until 1.9.2, released a year after 1.9.1, and 4 years after 1.9.0, the 1.9 branch was too unstable for production use. Why were 1.9.0 and 1.9.1 GA releases again? The GC also still sucks, so the performance improvements from 1.9 are mostly nullified in real world applications.
Sometimes I wish the work on alternative implementations would be devoted to effort on MRI, but I understand this is a much more complex issue than it appears on the surface. It seems like all of the developers interested in real change in MRI that have the skills to make that change have hopped on to more interesting alternative implementations or left Ruby altogether.
While I've put JRuby in production for some smaller, non-Rails codebases that used JVM libraries, I've tried to run some non-trivial Rails applications on JRuby and it's just too slow for development work. Load time on code seems to be an order of magnitude slower, which is real time that adds up over a day worth of work to be something significant, so I'm back to REE. Rubinius is cool and they've come an amazingly long way, but personally I think the project suffers from what I'm going to call "sufficiently smart compiler" syndrome. After 5 years of work, they're still not even close to JRuby or MRI performance on real-world applications.
I've spent hours and hours understanding the technical and human reasons why all of these problems exist, but unfortunately the reality of shipping things trumps.
I guess that's why I've got this Clojure book in front of me.
The key with 1.9.3 is it's essentially work on producing a better implementation internally. The language is mostly unchanged since 1.9.2 but 1.9.3 is a lot faster in specific situations. Couple this with the newly customizable GC settings (I'll be blogging about this shortly) and 1.9.3 is shaping up to be a fine release. 37signals are already using it in production, even.
Does anybody know if the parallel tests will be ported to test-unit 2.x? Or if it is actually using minitest to do so: Is there a way to get minitest to output junit compatible xml? (ci_reporter doesn't support minitest)
First, let's say you subclassed String or have a delegate. obj.prepend(str) will adjust obj in place rather than create an all new String object (as str + obj would). This may be either desirable or critical, depending on what you're doing.
Second, prepend is a lot faster than using + in this case. As in, a simple prepend runs in a mere 1.9% of the time (in a benchmark I just ran). Why? Fewer new objects are being created. And that means easier and fewer GC runs too.
Update: I think there is something slightly bust since on 1.9.2 using + handily beats prepend on 1.9.3. But GC has changed a lot. I'll retest on RC1 rather than preview1 ;-)
Conventionally, "bang" methods should only be created as 'dangerous' versions of non-bang methods. There was no non-bang method to make a 'dangerous' version of in this case so it's non-bang by default. This is a commonly misunderstood naming convention in Ruby (and I dare say I don't even understand all the intricacies!)
There are quite a few examples of this in Ruby. For example, Array#keep_if which changes an array in place.
Sometimes I wish the work on alternative implementations would be devoted to effort on MRI, but I understand this is a much more complex issue than it appears on the surface. It seems like all of the developers interested in real change in MRI that have the skills to make that change have hopped on to more interesting alternative implementations or left Ruby altogether.
While I've put JRuby in production for some smaller, non-Rails codebases that used JVM libraries, I've tried to run some non-trivial Rails applications on JRuby and it's just too slow for development work. Load time on code seems to be an order of magnitude slower, which is real time that adds up over a day worth of work to be something significant, so I'm back to REE. Rubinius is cool and they've come an amazingly long way, but personally I think the project suffers from what I'm going to call "sufficiently smart compiler" syndrome. After 5 years of work, they're still not even close to JRuby or MRI performance on real-world applications.
I've spent hours and hours understanding the technical and human reasons why all of these problems exist, but unfortunately the reality of shipping things trumps.
I guess that's why I've got this Clojure book in front of me.