

Ruby 1.9.3 RC1 is out - telemachos
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/388203

======
rbranson
_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.

------
masnick
Here's a list of what's new in 1.9.3:
[http://www.rubyinside.com/ruby-1-9-3-introduction-and-
change...](http://www.rubyinside.com/ruby-1-9-3-introduction-and-
changes-5428.html)

Scroll down on that page for some more lengthy explanation.

~~~
petercooper
Thanks for linking to my article! There's also
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-
talk/...](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/388203)
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/>)

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

<https://gist.github.com/1117138>

~~~
petercooper
Pathname also. For anyone unfamiliar with it: [http://ruby-
doc.org/stdlib/libdoc/pathname/rdoc/classes/Path...](http://ruby-
doc.org/stdlib/libdoc/pathname/rdoc/classes/Pathname.html)

------
chrismealy
Does this do anything for rails startup time?

~~~
hasanove
<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."

~~~
atambo
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>

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

------
phzbOx

      rand(1..10)
    

is now possible, cool!

Also:

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

might be useful.

~~~
trebor
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.

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

~~~
getsat
#prepend replaces _in place_? There's no #prepend! ?

~~~
petercooper
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.

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

