Work has started on Ruby 2.0

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

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.

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.

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.

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.

It's not just for things like Rails apps that Ruby is typically used for, either. I frequently process data, such as large log files, and now and then I try out the different Ruby to see if things have gotten better. So far, 1.9 and JRuby are the winners.

(LuaJIT is typically 2-5 times faster than both, so these days I tend to write my scripts in Lua.)

Without the GIL what does that mean for extensions written in C. Would they need to be rewritten?

https://bitbucket.org/pitrou/t3k/wiki/Home

It's described as "an experimental, work-in-progress port of Twisted to Python 3".

Python 3 is exactly how not to do a major language change. They broke enough that porting isn't trivial, and for many programs there just isn't any benefit. Plus the performance noticeably regressed.

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.

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.

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.