Live data from Hacker News

Work has started on Ruby 2.0

github.com

31–40 of 62 posts

Re: Work has started on Ruby 2.0

#31
post #8

Earlier quoted context omitted.

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

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…

> 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

Part of the reason that the urge isn't quite there is because there hasn't been enough time for 3.x to diverge from 2.7, the end of the 2 line. 3.2 came out eight months after 2.7 and the feature differences aren't large, especially considering that 3.2 was developed at the same time as 2.7 so many of the newly added features are the same.

As 3.x continues on with the 3.3 release next fall, the differences will become greater, the feature sets will become different, and the urge may start rising. As was said before, this is all measured in years - we can't expect that 3.x (the interpreter and standard library, on its own merits) just suddenly jumps ahead.

Re: Work has started on Ruby 2.0

#32
post #16
post #15

Earlier quoted context omitted.

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

Thats the user perspective. I don't see the MRI team, which has built a whole tool-chain around developing MRI throwing away all that and to switch to a new platform. I like Rubinius very much, as I do with JRuby, I just don't see Rubinius replacing MRI. Thats what I meant by 'dreaming'. A non-realistic expectation that is not backed by any real events.

Outside the MRI team, what the MRI team get up to only matters as long as the community pays attention to them.

If everyone decided to switch en masse to Rubinius, MRI might not go away, but it would definitely be sidelined into irrelevance.

Re: Work has started on Ruby 2.0

#33
post #20
post #17

Earlier quoted context omitted.

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

I know that they are on a good track towards 1.9 support. My point still stands: they are not there yet. So, if you were an MRI developer: would you switch to an interpreter where would have to build that whole stuff from the last 3 years again?

I can imagine a world where Rubinius never gets 1.9 encoding support, and declares it a non-goal. It's not that outlandish.

Re: Work has started on Ruby 2.0

#34
post #30

Earlier quoted context omitted.

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.

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

That would take even longer for serious production to switch to Rubinius. Especially when people have invested a lot in terms of learning how to boost MRI performance to the last drop.

Re: Work has started on Ruby 2.0

#35
post #30

Earlier quoted context omitted.

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

That would take even longer for serious production to switch to Rubinius. Especially when people have invested a lot in terms of learning how to boost MRI performance to the last drop.

Yes, it would not be a painless change. But neither has the switch from 1.8 to 1.9 been pain-free. Just because it's hard doesn't mean it's not worth doing.

Re: Work has started on Ruby 2.0

#36
post #23
post #18

Earlier quoted context omitted.

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.

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.

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.

Re: Work has started on Ruby 2.0

#37
post #9

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.

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.

Re: Work has started on Ruby 2.0

#38
post #9

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.

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.

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

Re: Work has started on Ruby 2.0

#39

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

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

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

Re: Work has started on Ruby 2.0

#40
post #36
post #23

Earlier quoted context omitted.

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.

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.

But you have noticed that MacRuby is an MRI fork?
Post reply on HN