
Ruby 2.0.0 Released - haven
http://www.ruby-lang.org/en/news/2013/02/24/ruby-2-0-0-p0-is-released/
======
donw
Overall, a good feature set. I only see some utility for keyword arguments,
admittedly, but I tend to write very functional code, so maybe other people
will get more mileage.

Refinements, as I understand them, are a bad idea.

I understand the motivation, but this is not the way to go about it. There's
now a new scope all over the place (the set of refinements applied to any
given class). This means that the behavior of any given class now can depend
heavily on context.

This makes optimization a bitch, for the same reason that it makes programming
a bitch. I can now have two Strings, one Refined by ActiveRecord, the other
Refined by Sequel, which expose a different set of incompatible methods.

~~~
jacquesc
Totally agree about refinements. Hopefully the community pushes back enough on
that experiment so it gets deprecated and removed.

A better design approach to achieve this effect is wrapper objects (similar to
jQuery and Underscore.js) where I can add functionality to existing objects.
Ruby has everything we need for this already, and makes it quite easy to do.

~~~
nnq
Aren't refinements a "fixer feature", i.e. something 99% of developers should
just ignore it until they really get into a problem with badly done
monkeypatching, then use it to solve the problem and just move on? Why do
people get so excited about them, both in a good and in a bad way? Just use
them inside your library code and make sure people using your lib/framework
can just pretend they don't exist, keep monkeypatching "chained inside" as
your dirty little secret:P)

~~~
tomstuart
Charles Nutter does a good job of explaining why you can't just ignore
refinements: <http://blog.headius.com/2012/11/refining-ruby.html>

In summary, they makes the Ruby language harder to implement, and Ruby code
harder to understand. You can't pretend they don't exist if their existence
compromises the meaning of your code and the performance of your chosen Ruby
implementation.

------
noelwelsh
I do wonder about the long term success of Ruby. Rails is easily the most
visible project for Ruby. Rails is big, and all that code represents a high
barrier to entry for any framework in a different language that wants to
compete. However, a lot of people I talk to are moving to pure JS front-end +
REST backend. In this world Rails doesn't deliver any particular value (in my
opinion).

Ruby also has utility for doing lots of scripting type tasks (things like
Jekyll). The libraries you need to do this are simple to write. Python is
perfectly adequate for this task already, as is Node (modulo callback
spaghetti). So there is no barrier to entry here.

In summary I don't see any project going forward that provides enough value to
maintain interest in Ruby. Thoughts?

[NB: I'm not saying Ruby is going to die overnight. I just think it will
slowly become less relevant.]

~~~
smnrchrds
> I just think it will slowly become less relevant.

That's true for virtually anything. Do you think C/C++ or Java or JS will be
mainstream 30 years from now. They will be in the same situation FORTRAN is
today: important because of lots of legacy code, but not a viable choice when
starting a new project.

Of course some of them will never die. LISP comes to my mind. :-)

~~~
PommeDeTerre
C and C++ will very likely still be "mainstream" 30 years from now.

Essentially every important piece of software today, from operating systems to
programming language implementations to server software to applications, is
written in one or both of them. All of these systems are not just going to go
away.

C is over 40 years old, and C++ around 30, yet in that time nothing has come
along that can compete with them. Some other languages have tried, but their
success has only ever been partial, and typically in just one or two specific
domains.

~~~
whalesalad
Go is making a strong go at it. No pun intended.

~~~
PommeDeTerre
Go hasn't really seen much success. It isn't as obscure as many other
languages, and being supported by GCC does help it out, but we haven't seen
any major adoption of it. Maybe that'll change at some point, but it doesn't
look very likely.

------
ScotterC
Basic Ruby 2.0 benchmarks calculating pi from gist [1]

$ ruby --version

ruby 1.9.3p385 (2013-02-06 revision 39114) [x86_64-darwin12.2.1]

$ time ruby pidigits.rb 10000 2>&1 > /dev/null

17.51s user 0.11s system 99% cpu 17.639 total

$ ruby --version

ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.1]

$ time ruby pidigits.rb 10000 2>&1 > /dev/null

4.64s user 0.27s system 99% cpu 4.927 total

That's a significant difference in speed. Going from 17.51 seconds to 4.64
seconds

1\. <https://gist.github.com/thoughtpolice/5025417>

~~~
mrgordon
If we see these sorts of improvements overall, then this is a _very_ exciting
update

~~~
ScotterC
Agreed. Testing against some of my production apps now to get a better feel.

~~~
kawsper
How did it go?

------
jacquesc
This is pretty exciting. Might be too early to tell, but it feels like the
Ruby versioning recently has been done very right. The switch from 1.8.x to
1.9.x was slightly painful, but I think 80% of Rubyists have made the jump.

I'm hopeful and expecting the switch to 2.0 by 80% of Rubyists in 2013.

Compared to the adoption of major version releases by Python/Java/C#/PHP, I
think that's something the Ruby core release team can be proud of.

~~~
aaronblohowiak
1.9 was not supposed to be a wide release, and it contained more breaking
changes than 2.0, IIRC.

~~~
jacquesc
I'm not 100% sure on the history, but I believe 1.9.x started as a dev release
and then they changed their minds and decided it was a wide release. That
initial confusion might be why the community took the time to go from 1.8 to
1.9.

I think they've learned from that, as 2.0 looks like a much cleaner/easier
transition.

~~~
stormbrew
On the other hand, it means we've now had point and minor releases that broke
everything (1.9, 1.8.7, and I think even one or two of the 1.8.7 patch
releases actually backported breaking 1.9 features), while the major release
is apparently one where nothing from the prior release should break. I'm not
convinced that means they've 'learned their lesson' so much as that they still
don't know how to version things.

We'll see how 2.1 goes, I guess.

~~~
Kerrick
Indeed. I hope that ruby itself starts following the semantic versioning [0]
that is so popular with ruby developers. Now that they have a "clean slate"
with a 2.0.0 release, they could!

[0] <http://semver.org/>

------
grey-area
There are some nice features here:

 _Keyword arguments, which give flexibility to API design_

This looks good to replace all those options hashes in rails for example,
though I wish they'd made it an all or nothing thing, apparently you can still
do this:

    
    
        def foo(x, str: "foo", num: 424242)
    

i.e. use some named and some unnamed in the same method which looks ugly.

 _Module#prepend, which is a new way to extend a class_

Compared to something like Go, I do worry the Ruby inheritance picture is
becoming overly complex, but I guess there must have been some use case for
this - anyone know where it is going to be used?

 ___dir__, which returns the dirname of the file currently being executed_

This is a great little enhancement which means I can replace
File.dirname(__FILE__) from the start of a lot of utility scripts. Would love
to have seen more little improvements like this.

 _The UTF-8 default encoding, which make many magic comments omissible_

At last! This should have been in 1.9.

 _Performance improvements_

While these are incremental, it's nice to see more improvements - thanks Ruby
team!

 _Onigmo, which is a new regexp engine (a fork of Oniguruma)_

Not sure what this changes from Oniguruma.

 _Refinements_

Refinements seems to be the headline feature for a lot of people, but I have
two hesitations about it: it's encouraging a practice which has come to be
seen as one of the most dangerous parts of Ruby - monkey patching, and the
process of deciding its inclusion seems to have brought about a few schisms
with the community developing alternative Ruby implementations because of
performance implications, and raised wider issues about the Ruby design
process:

[http://www.confreaks.com/videos/1278-rubyconf2012-toward-
a-d...](http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-design-for-
ruby)

There is the argument of course that it's attempting to limit monkey patching
and therefore limit the damage caused, but should it be encouraged at all?
It'd be interesting to hear more on what happened here from anyone has been
following this closely.

~~~
vidarh
Module#prepend doesn't look too bad from me from a complexity perspective -
inheritance in Ruby boils down to two parallel trees: One of the inheritance
chains, and one of the method lookups. Really we're dealing with a single tree
of "actual" inheritance, with some of them being "hidden" in some contexts. It
gets a bit complex if you want to do meta-programming or do something that
depends on the inheritance hierarchy, but mostly it behaves the way people
expect in regular use.

Refinements, on the other hand, looks brain-damaged to me. I see the
rationale, but the outcome looks more complicated and error-prone than the
situation it is trying to address...

And it looks like the type of thing that will "infect" other code, just like
C++ code for a while got infections of throw specifications on member
functions, that then got propagated all over the place and cause major pain
every time you tried to modify code. Until most people stopped using them much
again except in very limited circumstances.

~~~
grey-area
Yes it's not hugely complex, but it does complicate the composition side of
code inheritance a little more as you have to think about how a module might
be included as well as which modules and which superclasses you have. Contrast
this with go which has no inheritance and only simple composition and is
vastly simpler to comprehend re the reuse of code due to those limits.

Re refinements I agree and find it worrying that it was added given the
widespread objections.

------
jayferd
And this day shall be know as Ruby Two's day.

~~~
jayferd
I've been waiting for that for a long time ._.

------
marvwhere
my personal best new feature is:

"The UTF-8 default encoding, which make many magic comments omissible"

because i'm from Germany and we had to add: # coding: utf-8

in every freaking controller to get our german stupid letters (öäüß) to run
without problems.

so i'm looking forward to my next project where i can use 2.0 from the
scratch.

thank u!

~~~
kawsper
Why are you writing special characters in your controllers?

We are Danish, and are writing comments in English, and all locale strings is
placed in i18n-files.

------
AlexanderDhoore
Anyone have any thoughts on why python and ruby are so similar, yet so far
apart? They are obviously very close, because people switch between them all
the time. And they are compared on everything (languages features, libraries,
tooling...). I think it's a healthy competitive environment.

~~~
PommeDeTerre
The biggest difference is the communities surrounding each, and the impression
each leaves on people.

When I think of "Python", I think of a mature, helpful, experienced, talented,
well-educated community. I can generally trust their advice, I can trust their
code, and I can trust their technical decisions. It feels like collaboration
is important and encouraged.

The Ruby community, whether this is deserved or not, leaves a very different
impression. Anything good is quickly and heavily overshadowed by the
unnecessary and petty drama, the egos, the fixation on worshiping certain
figures in the community (DHH, Zed, why the lucky stiff), poor technical
decisions, inexperience, repeated displays of very immature conference
behavior, and so forth.

In can reflect very poorly upon a language when the community is generally
toxic, like in the case of Ruby, or very positively when the community is
generally superb, like in the case of Python. This is true even when the
languages themselves are rather similar, from a technical perspective.

~~~
patallan
I think this is a little unfair - you do prefix your thoughts on the Ruby
community with 'whether this is deserved or not', but then treat your
perception of the community as fact.

I'm a Rubyist, and I've found that the vast majority of the community, events,
interactions, etc are smart and civil. Yes, the Ruby community does have a bit
of a publicity problem, but that's just the noisy/stupid minority.

Perhaps this is a common issue more broadly. (Are all PHP developers stupid?
Are all lawyers money-hungry scum? Do politicians have no regard for
intelligent discourse?) Our media (whether that be mainstream or Twitter and
HN) is great at highlighting the controversy, but not a good source for a
deeper understanding of the lay of the land.

------
charlieok
2.0 on the 20th. Happy 20th!

~~~
irmbrady
Ruby is now also 20 years old.
<https://twitter.com/yukihiro_matz/status/305334327938519040>

~~~
charlieok
That's what I meant - 20th birthday

------
kybernetyk
I've been waiting for native keyword arguments for years. A great addition
that should make code more maintainable.

------
oleganza
I guess, Rubinius is no longer relevant? I remember it was a very promising
project back in 2008.

~~~
jxf
Evan Phoenix (the creator) left in 2012 to work for LivingSocial. EngineYard,
his former employer, had been funding work on it last I heard, but there
haven't been any releases since 2011.

<http://blog.fallingsnow.net/2012/03/28/a-new-door-opens/>

~~~
steveklabnik
> there haven't been any releases since 2011.

Every commit is a release of rbx. Yay continuous integration!

That said, there hasn't been a numbered release in a while, through there will
be a 2.0.

~~~
jxf
Yes, sorry for not being clearer. I'm basing the "there hasn't been a release
since 2011" comment off of the Rubinius homepage, where the last numbered
release is 1.2.4.

The Rubinius 2.0 preview release came out in June 2011:
<http://rubini.us/2011/06/07/inside-rubinius-20-preview/>

------
thetron
Congrats Ruby team - really well done. 20 great years.

------
ashokvarma2
Is ruby 2.x faster than 1.9.x. Any benchmarking data?

~~~
haven
Yes, there are performance increases. Sasada-san gave a good talk at RubyConf
this year on 2.0.0's internals and performance enhancements:
[http://www.confreaks.com/videos/1272-rubyconf2012-implementa...](http://www.confreaks.com/videos/1272-rubyconf2012-implementation-
details-of-ruby-2-0-vm)

------
phasevar
My favorite new feature. Keywords arguments. As a Python convert, I really
missed those.

~~~
aviraldg
Just curious: what made you switch?

------
pkmiec
I totally agree about refinements being a terrible idea. Brian Ford (of
Rubinous) makes an excellent argument:
<http://www.youtube.com/watch?v=BagNfTbXn3w>.

What is the best way to let Ruby team know that refinements are a bad idea?

~~~
steveklabnik
> What is the best way to let Ruby team know that refinements are a bad idea?

Get involved in the discussions on ruby-core.

------
randomsearch
Serious question - should I learn Ruby?

I spent a little time looking at Ruby in the past. It seems like a nicely
designed, clean language. However, it seems to me that it lost to Python in
many domains. In addition, I've heard stories about Ruby having performance
problems. For example, I heard Twitter rewrote their backend in Java/Scala
because Ruby didn't perform well enough.

Recently I was at a Cloud Computing symposium thing attended by academics and
industrial developers. No-one in the room was using Ruby for development
anymore. Has it died? Is there any point learning it?

~~~
ikailan
Learn what you want to learn, because your tools will change. Many Ruby
programmers came to Ruby because of Rails. I'm part of the camp that stuck
around because of JRuby for a while, but nowadays I find that I write very
little Ruby and a lot more Python.

Don't worry too much about what you hear about performance. If you are
building a Twitter, then yes, it might matter what language you're learning.
Ruby, Python, and PHP tend to be in the same ballpark in terms of performance,
with each having their own warts.

As of late, I've been most interested in golang.org. You can learn the basics
in an afternoon at tour.golang.org.

~~~
randomsearch
Cool, thanks. Actually, Go was an alternative I was considering for my next
language. More worthy than Ruby? Is it a possible Python replacement?

------
JulianMorrison
I wonder, is asynchronous exception handling going to make exceptions useful
in evented/fibered code? Because right now, the ability of your stack frame to
unpredictable blow up is a complete nuisance.

------
moron4hire
Congrats, Ruby Team. Always good to see a new release. Onward and forward.

------
fersho311
I was stuck on this for a few hours, so hopefully this might help someone. If
you are install ruby 2.0.0 with rvm, make sure you do rvm get head before
doing rvm install 2.0.0 or rvm reinstall 2.0.0

------
copx
I like Ruby but keywords arguments are the solution to a problem which
shouldn't exist in the first place. Namely functions like..

myFunction(something, 23,23,100, somethingElse, true)

People should write smaller, more specialized functions instead (less
arguments). That makes software both: more efficient and more maintainable.

If you start thinking: "Damn I wish I had keyword arguments to make this
function call more comprehensible!" .. the problem is elsewhere.

~~~
TylerE
100% disagree. For some use cases they are very useful. Like, imagine a
function that generates an HTML snippet, and can optionally assign some
specific class names/ids to some of the elements.

~~~
MBCook
As much as many people seem to hate the way Objective-C does things, I really
like how it intersperses the arguments in the function name. It makes it so
easy to identify parameters.

Most languages:

    
    
      someObject.throwProduce(apple, myEnemy, 14, 17);
      

Objective-C:

    
    
      [someObject throwProduce:apple at:myEnemy withForceInN:14.0 maxDisanceInM:17.0];
    

As long as you name the function appropriately, it's clear what each parameter
does without having to look up the name. Many people complain about the long
names (in this case
throwProduce:at:withForceInN:maxDistanceInM:thenWaitInMS:), but it avoids the
situation you have in other languages where there are 4 functions with the
same name but different signatures. In Obj-C the naming conventions discourage
such ambiguity and encourage self-documenting names.

------
jdelsman
Just submitted a pull request to Homebrew to have this added. Can't wait :-)

~~~
whalesalad
I'd definitely look at rbenv. Combined with it's plugin ruby-install, you've
got a pretty simple and powerful alternative to rvm. I use it exclusively.

~~~
zaius
rbenv is definitely better than rvm, but if you use the same ruby version
between all your projects, a single version of ruby installed through homebrew
is a much better way to go.

------
JulianMorrison
Does anyone here have a link to the new rubydocs for this?

------
mikaelf
We need tutorials. Videocasts! Please.

------
schiang
Nice. Time to use to_hash.

------
ksec
Still waiting for Ruby 2.0 Benchmarks

------
hcr
Congrats! Great works

------
bau5
ruby pls

------
zopticity
Ruby rocks my socks.

------
tferris
Today, I'll lose at least 50 karma points, but it's worth:

Why people still use Ruby?

1\. Because they get dream day rates for maintaining rusty slow legacy systems

2\. Because they do not want to learn new languages and can stay in their
comfort zone

3\. Because they think it's still 2005 and nobody cares about slow server
response times

And now Ruby lovers, click on downvote or give your reasons why you still use
Ruby.

~~~
tykko
Ruby lovers are all about "feelings" and "style", they don't care if their
language of choice is objectively worse than, say, Python or Lua.

Ruby truly is the Apple of the programming world.

~~~
nsmartt
I fought with Python for weeks before I picked up Ruby. It clicked perfectly
and I've never had to fight with it.

I don't see how Python can be _objectively_ better than Ruby.

I don't know enough about Lua to comment.

