
Ruby 2.2.0 Released - kokonotu
https://www.ruby-lang.org/en/news/2014/12/25/ruby-2-2-0-released/
======
jayroh
To the people who maintain the tools and platforms around these large version
updates - thank you. rvm, ruby-build, homebrew, heroku - you're all truly
generous for having everything ready for us almost immediately (on Christmas
morning no less).

You're all wonderful- merry Christmas! <3

~~~
Artemis2
Well, I wouldn't say that Heroku does that out of generosity, but their free
tier is pure gold.

~~~
jayroh
They certainly didn't have to get the support for 2.2.0 out on Christmas
morning, but they (actually, Terence) did.

[https://twitter.com/hone02/status/548131759762968576](https://twitter.com/hone02/status/548131759762968576)

Although with Matz an employee I'm sure they were well ahead of the curve. ;)

------
mrmondo
Great work to the ruby team, the improvements in Ruby's performance since 2.x
have been very impressive to say the least. Well done and Merry Christmas to
everyone that worked hard on this release.

~~~
kawsper
Indeed, by upgrading Ruby from 1.9.3 to 2.1.2 we cut the time spent running
our specs in half for our Rails project.

~~~
ch4s3
I just popped off a branch of my production Rails 4.1.8 app (Can't quite do
4.2 yet), and upgraded it 2 Ruby 2.2. I ran 271 spec against it 5 times before
the upgrade and 16 times after. I should have done more before :(

For 2.1.5

AVG: 18.02

MEDIAN: 18.11

MIN: 16.26

MAX: 19.6

For 2.2

AVG: 18.162~

MEDIAN: 15.23

MIN: 14.44 <\- nice

MAX: 47.03 <\- first run, wut?

It looks better, but I haven't profiled the app on Passenger yet to see how
well it plays with the whole app.

------
xfalcox
Guys, I made a very simple pull request regarding auto proxy detection on the
standard library of ruby, but it still open after a little while. Someone here
have some directions on how to contribute correctly to the project?

~~~
shadeslayer
I contributed a small patch earlier this month, but used their bug tracker to
submit patch, turn around time was ~24 hours I think. See bugs.ruby-
lang.org/issues/10551

So I think all of their patches need to go through the bug tracker.

~~~
xfalcox
Thank you! Just submitted it at [https://bugs.ruby-
lang.org/issues/10652](https://bugs.ruby-lang.org/issues/10652)

Hope it helps!

------
hit8run
Ruby seems to continuously move forward. Great to see that they manage to keep
this project alive without a python 2vs3 disaster.

~~~
berdario
Sure, but be aware that if Ruby ever decides to fix the situation with its
Strings types/encoding, you'll get the exact same "disaster". At least in the
python world this change is now mostly in the past.

~~~
matthewmacleod
What situation is that, out of interest?

As of Ruby 1.9, there's a pretty sensible solution to this in the language,
and I haven't had any encoding problems in some time. I appreciate I might
have missed something though!

~~~
berdario
(I'll try to keep this short, since I feel this is quite offtopic, if we want
to discuss this further I suppose we could find a better venue... maybe even
email?)

I assume that with "Ruby 1.9 solution", you refer to the fact that Ruby source
code is by default evaluated as UTF-8, right?

That's definitely a good thing, but with Python3 that wasn't the only change
brought into the language.

I said "if Ruby ever decides to fix", because the need for a change is not
obvious and not universally accepted: it's basically the same issue as
automatic type coercion (aka weak/strong typing) and early (or late)
raise/throw/handling of exception.

Basically: In Python2 and Ruby you have one or two String types (runtime
types, in this discussion I only care about them), with the Ruby Strings
tagged with the encoding internally used. In python the types are just
"anything goes" (binary strings, the old Python2 string) and unicode (the
actual internal encoding is an implementation detail).

The problem (if you agree that it is one) is that you can easily mix-and-match
them, and everything will work fine only as long as the operation makes sense.
When it won't anymore you'll get an exception.

This is a problem when you don't completely control the type/encoding of your
input (e.g. if you have an HTTP request and your string depends on the
type/charset specified in the Content-Type).

A dumb example of what could happen:

    
    
        a = "Ё".force_encoding "ISO-8859-5"
        a2 = "®".force_encoding "ISO-8859-1"
        # a + a2 will fail with Encoding::CompatibilityError
    

A similar thing can happen in Python2. While Python3 will reject the same
operation as soon as the types get in contact with each other (still at
runtime, but it'll be like doing `1+"1"` in Python or Ruby: you'll spot it
right away).

I wrote a quite lengthy blog post about this change in Python3, but I haven't
translated it in English yet, if there's some interest I could try to do it a
bit sooner.

Anyhow, I don't want to create a flame or anything like that. I just wanted to
explain why the Python3 choice has been made, and why a destructive change
might have had its merit. While I prefer the Python3's approach, and I'm
definitely not a Ruby developer, I still appreciate these updates to Ruby: for
example I actually touched first hand the internal encoding-handling code of
Ruby (Rubinius) some time ago with a friend of mine:
[http://git.io/7kM4Gw](http://git.io/7kM4Gw) and I can benefit from the new GC
code in new rubies, which makes metasploit 4 times faster to load.

~~~
jrochkind1
Actually, the "ruby 1.9" solution is having Strings tagged with encoding at
all -- prior to ruby 1.9 they were not, they were just bytes.

This was a pretty major change, I think I'd call it a 'destructive' change, it
was indeed a big pain upgrading apps from ruby 1.8 to 1.9, and character
encoding was the major issue generally.

I'm not sure I understand what you're saying about python 2 vs 3, or what you
think needs to be changed in ruby. If I understand right, you're saying that
it ought to be guaranteed to raise if you try to concatenate strings with
different encoding.

Instead, at present, for encodings that are ascii-compatible (which is most
encodings), ruby will will let you concatenate if both strings (or just the
argument and not necessarily the receiver? I forget) are entirely composed of
ascii-compatible chars, otherwise it will raise.

I think you're probably (although I'm not 100% confident) right that it would
be better to 'fail fast' and always raise, requiring explici treatments of
encodings, instead of depending on the nature of the arguments (which may have
come from I/O), which makes bugs less predictable. There continues to be a lot
of confusion about how char encodings work in rubyland, and it's possible a
simpler model would be less confusing (although I suspect char encoding issues
are confusing to some extent no matter what, by their nature).

In general, even as it is, I find dealing with char encodings more sane in
ruby (1.9+) than any other language I've worked in (but I haven't worked in
python).

If ruby ever decides to make things even more strict, I don't think it'll
actually be as disruptive as the 1.8 to 1.9 transition. For anyone who ever
deals with not-entirely-ascii text (and who doesn't?), they basically already
had to deal with the issue. Ruby was trying to make the transition easier on
the developer to make some circumstances where it would let you get away with
being sloppy with encodings -- I'm not sure if it succeeded in making it any
easier, the transition was pretty challenging anyway, and "fail fast" might
actually have been easier, I think I agree if that's what you're saying.

I don't know enough about python to have an answer, but I continue to be
curious about what differences resulted in the entire ruby community pretty
much coming along on the ruby 1.8 to 1.9 jump (and subsequent less disruptive
jumps), while the python community seems to have had more of a disjoint. I
don't know if it was helped by ruby's attempt to make the encoding switch less
painful with it's current behavior. Or if it's as simple as the 100-ton
gorilla of Rails being able to make the community follow in ruby-land.

~~~
MichaelGG
Excuse my density here, but why not just force all strings to be UTF8 and call
it a day? Anything in another encoding would need to get converted. What am I
missing that Ruby and Python need these complicated problems but other
platforms don't have these issues?

~~~
Xylakant
Han unification is the primary reason not to force utf8, especially in a
language that has strong roots in Japan. (Sorry to be short, I'm on a
smartphone. Googling should provide sufficient answers)

~~~
wycats
Han unification is one problem; another problem is that not all encodings can
be round-tripped losslessly through Unicode. Shift-JIS, for example, has
multiple separate characters that convert into the same character in Unicode,
and therefore cannot be converted back into their original form reliably.

~~~
wycats
Citation:
[http://support.microsoft.com/kb/170559](http://support.microsoft.com/kb/170559)

------
joshdotsmith
For rvm users, remember to run

    
    
      rvm get stable
    

before trying to

    
    
      rvm install ruby-2.2.0
    

You might end up getting preview1 unexpectedly.

------
blacktulip
Great work. Thanks for the Christmas gift.

btw: anyone else thinks Rails was mentioned too much in the release note?

~~~
briandear
Rails was mentioned once, unless I missed something.

~~~
blacktulip
Paragraph 3 and paragraph 4

------
rab_oof
Interesting: vfork support.

Vfork in most older systems is like fork except it doesn't deeply duplicate
all process state immediately (file handles, memory, such), so it can be
faster if all the app wants to do is fork/exec. (We had to implement both fork
and vfork in minix 2.x in uni.^)

But according to SO, most OSes implement fork lazily, so there's not much
point in using it when fork will be just as fast without any change.

If there were a slowly-performing platform that has a specific performance
issue identified by profiling as caused by fork, then mature optimization
could follow. Otherwise, it seems like adding LoC without a clear goal.

The Symbol GC sounds good. Maybe this will imply code can associated with
classes and modules can be GCed and required anew once all objects are freed
(live upgrade apps without restarts).

^ The first thing I did to the Minix codebase was set keyboard repeat rate to
the fastest possible values. Everyone else seemed content to waste their life
waiting for their editor and debugger to move at a snail's pace. Of course, no
else had x86 asm / pc hw io experience.

~~~
jordanthoms
Copy-on-write fork is much faster than copying everything, but there is still
some overhead setting up the copy-on-write state and dealing with the first
writes afterwards, I think in cases where you have large amounts of memory
vfork can still be useful.

~~~
rab_oof
The point isn't to prematurely optimize for edge-cases, but to tackle real,
"hair-on-fire" performance bottlenecks head-on. If that means asking large-
scale users to run profiling and getting stats of what's using tons of memory,
slowing things down, duplicating work or wasting IOPS, go for it. If it's a
dubious return/ effort at the expense of complexity, it might not be worth the
investment.

For example, 'FooBarWidget @ Passenger 5 "Raptor" is a well-crafted,
thoughtful achievement in terms of app servers.

2.2 Symbol GC also sounds great. I'm just not convinced there is enough
innovation to make Ruby an order-of-magnitude faster, use less memory / return
memory back to the system.

------
cmelbye
Not compatible with Rails 3.2.x, for those still on that version. (And
possibly will never be, as 3.2.x only receives security updates now.)

~~~
grandalf
What is the nature of the incompatibility?

~~~
cmelbye
One change is that test/unit is now no longer part of the standard library,
which Rails requires. The workaround is simple, "test-unit" must be added to
the Gemfile.

A less easily fixed change is that the following syntax no longer works the
same as it did in previous versions of Ruby:

    
    
        def foo(bar = bar)
    

The recommended fix is the following: (I believe)

    
    
        def foo(bar = bar())
    

Rails uses this syntax occasionally. It's simple to change, but the Rails team
refuses to merge in the fixes because it's not a security issue.

~~~
grandalf
Wow that's too bad.

Do you know if the Rails team would approve a patch that was submitted?

Also, the change of the meaning of the right bar in your example above seems
significant. Do you happen to know of any context for that change?

~~~
ehsanu1
In case you weren't aware:
[https://github.com/rails/rails/pull/18160](https://github.com/rails/rails/pull/18160)

------
current_call
It's a bit weird that symbols are garbage collected. I wouldn't think it could
delete them without making the same symbols unequal some of the time.

~~~
Argorak
They are only garbage collected if they were introduced at runtime and there
is no reference to them anymore. (detailed explanations can be found in the
presentation linked in the announcement)

This allows you to symbolize external hash keys without fear of a DOS attack.

------
calineczka
I have problem installing on ubuntu 12.04 :
[https://gist.github.com/paneq/fee5477fb7ab1ede0104](https://gist.github.com/paneq/fee5477fb7ab1ede0104)
. Did any of you experienced that as well?

~~~
elektronaut
Yes, and on 14.04 as well. Try installing the libffi-dev package.

------
arikrak
Anyone know how Ruby 2.2 works with Rails on Heroku (with unicorn)? When I
switched from 2.0 to 2.1, it caused all sorts of memory problems so I had to
switch back.

~~~
pomartel
I gave Ruby 2.2 a try with Rails 4.2 and the same memory problems that plagued
Ruby 2.1 also occurred. I am switching back to Ruby 2.0. Rails 5 will require
Ruby 2.2 and higher so I hope someone will find a way to fix this.

~~~
arikrak
Thanks for your answer (here and on SO). I guess I'll wait it out...

------
andersonmvd
The download URL should be HTTPS, but at least they informed the digests.

------
claudiug
nice! Hope that version 3 will add jit :)

