

Work has started on Ruby 2.0 - ben_hall
https://github.com/ruby/ruby/commit/6b8d4ab840b2d76d356ba30dbccfef4f5fd10767

======
plq
That sounds nice but, what's the plan? The closest I could find was this:
<http://redmine.ruby-lang.org/projects/ruby-20/roadmap>

~~~
Argorak
The plan is that the next major release is 2.0.0 and not 1.9.4, which means
that they can start talking about the Roadmap in the correct context. Don't
expect 2.0 to be released next year.

------
pdelgallego
If you are interested about what directions ruby will take in the future you
can read this thread in the ruby core mailing list.

[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-
core/...](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/39810)

~~~
mjbellantoni
I wish overall performance was on that list!

~~~
petercooper
Recent (and ongoing) garbage collection changes are effecting that. And
bytecode export/import will remove the parsing element on startup, at least.

Nonetheless, Ruby compares favorably against stock PHP, Python and Perl
nowadays. It's only one benchmark and it's possible to make any look faster
than the other, but Ruby is no longer miles behind everyone else:
[http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-fastest.php)

~~~
mjbellantoni
Oh, please don't think I am hating on Ruby and implying another language. It's
pretty much the only language I use these days.

I've been using it outside of a web-based context to do some more
computational intensive work and just get a little bummed when I need to re-
implement something in C to get the performance I need. (I'm not a C hater
either! I've just come to love Ruby.)

~~~
petercooper
No worries, I wasn't thinking that :-) There's a lot of uncertainty around
Ruby's performance and functionality based on people's experiences with 1.8
that no longer holds true in 1.9 (or when using implementations like JRuby).
I'm just doing my little bit to put fires out before they occur ;-)

------
jkjeldgaard
I can highly recommend Matz talk from RubyConf 2011, where he talks about the
future of Ruby.

[http://confreaks.net/videos/654-rubyconf2011-keynote-ruby-
ev...](http://confreaks.net/videos/654-rubyconf2011-keynote-ruby-everywhere)

------
compay
A lot of folks in the Ruby community were hopeful that Rubinius would replace
MRI to become Ruby 2.0. Looks like that's going to have to wait a little
longer now.

~~~
Argorak
It will most likely never happen. Also, Rubinius still has to fully implement
Ruby 1.9, so its not like you could just flip a switch.

On a side-note, a lot of folks are also dreamers.

~~~
compay
It's not like MRI 2.0 is right around the corner either. A lot of work will be
needed to get 2.0 out the door - potentially years. That work could instead be
applied to Rubinius, and the release schedule could end up being similar.

If it's "just a dream," it's largely for human reasons rather than technical
ones.

~~~
Argorak
There are huge technological reasons as well. MRI is included in OS X, some
Linux distros and even embedded in some systems. So there is a group of people
that is interested in keeping exactly this system.

Also, I have yet to see a purely technological decision of that magnitude,
even in the world of compilers.

I see Rubinius and JRuby winning the race, but I don't see any of them
_replacing_ MRI.

~~~
compay
MacRuby also already comes with OS X - though it's currently still a private
framework. By the time MRI 2.0 is ready to be released, the world will be a
different place, MacRuby could by that time be the default Ruby on OS X.

I understand there are good reasons to keep MRI around, but the idea of making
Rubinius the future of core Ruby development is not an outlandish idea.

~~~
Argorak
But you have noticed that MacRuby is an MRI fork?

~~~
compay
Yes. What's your point?

~~~
Xylakant
Well, if rbx became the default implementation, lots of the effort that was
invested in MacRuby would go stale. There's an incentive for the MacRuby
people to keep investing into MRI since they can more easily adopt
improvements from there. The benefit they get from taking code from MRI will
diminish over time, but at least ATM I'd still expect it to be significant.

(note: I'm not following MacRuby Development very closely at the moment.)

~~~
lobster_johnson
While MacRuby is a fork, they have already replaced the VM with one that
compiles to LLVM, which has been implemented in C++. They have also gutted
things like String and Hash to use Objective-C's (or more precisely, Cocoa's)
counterparts, and they have started using libdispatch (aka Grand Central
Dispatch), Apple's open-source multicore tech.

One of the big things about the new VM is that it eliminates the global
interpreter lock, meaning MacRuby probably has much better parallelization
than MRI. With the VM alone I think they are on their way to being their own
Ruby implementation.

All of this is a bit disappointing considering that they could have shared
their improvements upstream and improved MRI performance for everyone, not
just for Mac apps.

------
terhechte
Let's hope it will gain more acceptance and usage than Python3. Do they intend
major changes?

~~~
pdelgallego
For good or bad, the ruby community tends to embrace changes faster than the
Python community. For example Rails is going to drop 1.8.7 support in the next
release 3.2

~~~
lloeki
From personal experience the community at large is eager to move to Python 3.
It has more to do with tremendous inertia generated by critical components
being tricky to port to Python 3. Usual suspects Django and Twisted come to
mind. IIRC NumPy gained support only recently.

The Wall of Shame gives a very partial overview of the situation:
<http://python3wos.appspot.com/>

It does not help that useful stuff from 3.x get backported to 2.x or available
via __future__, and that IMHO Python 2.7 is awesome so the urge is not quite
there (well, not as much as working with Ruby 1.8 when you tasted 1.9)

~~~
jnoller
If you would like more resources than the FUD laden wall of shame, feel free
to visit: <http://getpython3.com/>

The timeline for Python 3 adoption was always measured in years - not one, not
two, but more. We're not a development team or group that cough up unicorns
about how long adoption of a backwards incompatible version will take.

Django has a Python 3 roadmap, as does twisted, as does PyPy, Numpy, etc. The
PSF and _companies_ are now funding Python 3 ports.

The reports of death are grossly overstated.

~~~
dextorious
> The timeline for Python 3 adoption was always measured in years - not one,
> not two, but more.

Already a lot of YEARS have passed, not one, not two, but more. We're even in
3.2 for heaven's sake.

> Django has a Python 3 roadmap

Yeah, has had one for years. How is that going?

> The reports of death are grossly overstated.

The reports of movement in this front are grossly overstated too.

