Work has started on Ruby 2.0

https://github.com/ruby/ruby/commit/6b8d4ab840b2d76d356ba30dbccfef4f5fd10767

by ben_hall • 15 years ago

80 61 15 years ago

terhechte• 15 years ago

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

pdelgallego2• 15 years ago

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• 15 years ago

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)

jeremykemper• 15 years ago

Rails 3.x will maintain 1.8.7 support.

Rails 4 will drop Ruby 1.8 for good.

Check out how quickly 1.9.2 has been adopted in production Rails apps: http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-rub...

petercooper3• 15 years ago

Not a direct answer to the question but Ruby 2.0 is expected to be backwards compatible with the current production release, 1.9.2, while just adding extra features. I'm not particularly well versed in Python 3 but I believe it wasn't intended to be backwards compatible.

Argorak7• 15 years ago

I think the best thing about Ruby is the really fierce competition between implementations, which also reflects on the developers. The Ruby community is used to ensuring compatibility between JRuby and MRI(1.8 and 1.9) for a long time now and Rubinius support is getting `en vogue`. Projects like Travis will ensure that testing on 2.0 is "just" anther field on the build matrix.

dextorious3• 15 years ago

> I think the best thing about Ruby is the really fierce competition between implementations, which also reflects on the developers.

I don't see any fierce competition against implementations in Ruby. I see that in Javascript implementations (and in HTML engines), but not in Ruby.

I wish that was not the case, but for real competition to exist, and also be fierce, each implementation should push other implementations to go better, adopt its successful features, etc.

What I do see is just parallel development of different implementations.

plq• 15 years ago

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

Argorak7• 15 years ago

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.

pdelgallego2• 15 years ago

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/...

mjbellantoni2• 15 years ago

I wish overall performance was on that list!

petercooper3• 15 years ago

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

jballanc• 15 years ago

It's best to think of performance in two contexts: implementation and semantics.

Performance problems that stem from implementation can be fixed, and can yield significant benefits. This work is continually ongoing in Ruby (see the recent GC improvements) and the proliferation of alternate implementations will benefit this effort significantly (see the speed improvements to JS resulting from competition between V8, Nitro, and IonMonkey). That said, these sorts of improvements probably won't appear on any roadmap, since they can happen without the knowledge of the language's users.

Performance issues arising from language semantics, on the other hand, are a very real concern for the roadmap going forward. Here, I'm thinking specifically about the refinements feature. Charles Nutter had an excellent breakdown of how this feature might have far-reaching impacts on performance here: http://redmine.ruby-lang.org/issues/4085#note-46 . Additionally, there may be avenues to improve performance by subtly altering the semantics of existing features (such as 'define_method'). Unfortunately, while these changes/features will be discussed as part of the roadmap, performance is typically only addressed in a bit of a side-long manner (i.e. if you want to know what the performance impact will be, you'll probably need to pay attention to the discussions on ruby-core).

All that said, I think you can rest easy knowing that, even though performance may not be a first-class concern for the Ruby 2.0 effort, it is something that the community is very cognizant of and will be paying attention to.

jkjeldgaard• 15 years ago

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

compay10• 15 years ago

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.

Argorak7• 15 years ago

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.

gnufied• 15 years ago

For a lot of folks, rubinius has already replaced MRI. At least locally while developing. I am not sure, why you are saying "It will never happen".

rue• 15 years ago

> Also, Rubinius still has to fully implement Ruby 1.9, so its not like you could just flip a switch.

The only serious piece missing from 1.9 is the encoding support. There's a number of other relatively minor failures remaining, but those are simple enough to fix (and several people, contributors new and old, are doing so at this very moment).

And the switch is -X19.

compay10• 15 years ago

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.

lobster_johnson4• 15 years ago

Considering that Rubinius is still considerably slower than MRI 1.9, that would be a big step backwards. Sure, considering that 2.0 will take a while to complete, one could put everyone to work on improving Rubinius' performance; but that would draw manpower away from non-performance work.

compay10• 15 years ago

Rubinius has a different performance profile from MRI. It's considerably faster at some things and slower at others.

chollida12• 15 years ago

Could you summarize what benefits moving to Rubinius would buy Ruby developers?

I'm an outsider looking in, so while I know what the MRI and Rubinius are, I don't know why I'd prefer to use Rubinius instead.

compay10• 15 years ago

* Written mostly in Ruby

* No GIL

* JIT

* Better garbage collector

* Better debugging tools

Unfortunately, Rubinius is not yet complete, so it's not a suitable MRI replacement for now.

filmprog• 15 years ago

I feel that there are many contributions that Rubinius has made to the interpreter movement. a) the race for performance against other interpreters, b) the creation of an official "ruby spec" that defines what the ruby language is , and thus makes both the interpreters and the main language better and c) created a movement itself that has many different goals and target audiences.

But I don't think that Evan, Brian, et al.'s goals have been to replace but rather further the movement of Ruby.

Work has started on Ruby 2.0

Related Stories