Ruby 1.9.3 RC1 is out | Hacker News Reader

Ruby 1.9.3 RC1 is out

blade.nagaokaut.ac.jp

96 pointstelemachos23 comments

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.

Here's a list of what's new in 1.9.3: http://www.rubyinside.com/ruby-1-9-3-introduction-and-change...

Scroll down on that page for some more lengthy explanation.

Thanks for linking to my article! There's also http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/... for a longer but more 'bulletpoint' list of items.

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.

(Plug: And for anyone on 1.8 who's ignorant of what 1.9 is about, I have something to help you at http://rubyinside.com/19walkthrough/)

Let's not forget Date got rewritten in C, so now it's fast:

https://gist.github.com/1117138

Pathname also. For anyone unfamiliar with it: http://ruby-doc.org/stdlib/libdoc/pathname/rdoc/classes/Path...

I'll hold on tight on my unit tests on this one - thanks for sharing!

Does this do anything for rails startup time?

http://redmine.ruby-lang.org/issues/3924

if i understand this correctly, it seems like it isn't...

"It can not be merged in 1.9.3, because it is late."

Actually, if you read through that issue there is a different patch that got accepted instead of xavier's that has similar performance improvements:

http://redmine.ruby-lang.org/issues/3924#note-45

i came to read the comments here hoping to find an answer to that question.

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)

  rand(1..10)

is now possible, cool!

Also:

  'est'.prepend('t') == 'test'

might be useful.

Why is

  "est".prepend('t')

more useful than

  "t" + "est"

? I don't see why a method for prepending to a string is necessary, when it is so simple anyway...

And random with a range parameter is useful shorthand.

Anyway, I'm more enthusiastic about performance improvements where file loading is concerned.

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 ;-)

Good point; I did not consider conserving objects and the overhead of allocation/initialization versus reallocation.

#prepend replaces in place? There's no #prepend! ?

No.

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.

I guess I misunderstood your definition of "in place". That jives with what I've understood about Ruby so far.

That would be redundant, since there would be no difference from String#+.

How does String#prepend compare to String#insert in your benchmarks? eg. "bc".insert(0, "a") # => "abc"

Sometime it's easier to chain with other functions and, depending of the situation, it might make the code easier to read.

More useful? It does a different thing, just like String#+ doesn't do the same thing as String <<.

They are not exchanges for each other. Rather - they are complements.

Not to mention more verb like - and thus descriptive.

Reply on news.ycombinator.com