Live data from Hacker News

Work has started on Ruby 2.0

github.com

21–30 of 62 posts

Re: Work has started on Ruby 2.0

#21

Earlier quoted context omitted.

I wish overall performance was on that list!

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-l…

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

Re: Work has started on Ruby 2.0

#22
post #15
post #14

Earlier quoted context omitted.

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.

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

> For a lot of folks, rubinius has already replaced MRI. At least locally while developing.

This in itself certainly is a great achievement for the rubinius team and one to be proud of. However, I personally have to see a large production deployment. I consider rbx a serious alternative to mri, just as jruby is a serious alternative. I'll call it "replacement" once heroku starts using rbx and drops mri support. I don't see that happening in the next couple of years, there's just way too much investment behind mri for it to just go away.

Re: Work has started on Ruby 2.0

#23
post #18
post #14

Earlier quoted context omitted.

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.

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.

Re: Work has started on Ruby 2.0

#24

Earlier quoted context omitted.

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-l…

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

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 ;-)

Re: Work has started on Ruby 2.0

#25

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

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.

Re: Work has started on Ruby 2.0

#26
post #18
post #14

Earlier quoted context omitted.

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.

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.

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

That may be true, but don't we all preach that "People matter, not technologies" all the time?

Nobody pretends that MRI 2.0 is round the corner, but rbx at the moment is not in a position to even replace MRI 1.9.2 (lack of windows support anyone?). Their current self-proclaimed status is 93% of the spec, so I don't think that stopping work on MRI and spending the next couple of month bringing RBX to the current MRI state is a valid alternative. Dropping MRI would also imply dropping the whole toolchain and all custom infrastructures based on MRI, lots of knowledge that people have with MRI would suddenly go worthless, etc...

I seriously don't see that coming in the next couple of years.

Re: Work has started on Ruby 2.0

#27
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…

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.

Re: Work has started on Ruby 2.0

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

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.

Re: Work has started on Ruby 2.0

#29
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…

In fact it's not a bad thing that 2.7 is so awesome - that makes it possible for people with large codebases to essentially put off the port to Python 3 for ever. Or maybe to skip Python 3 and port to Python 4 in another twenty years. Both are perfectly acceptable engineering decisions, and we are (or should be) talking engineering here, not religion.

As Jesse Noller has pointed out elsewhere, the transition was never intended to be instantaneous. The Wall of Shame might publicize those packages that are causing pain points, but it offers no prescriptions.

Re: Work has started on Ruby 2.0

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

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.
Post reply on HN