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.
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.
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...
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 ;-)
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.
> 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).
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?
Which is something that I'd regard as a major setback. Here in Europe, a solid encoding support is pretty much a must-have for any up-to-date programming language. There's much more than utf-8 and not being able to handle that is a deal-breaker for me.
Leaving aside the fact that encoding support is explicitly a goal, it would be an incredibly daft thing to do to decide that Rubinius was going to take a regressive, all-the-world-is-one-encoding point of view and break compatibility with much existing Ruby code.
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.
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.
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.)
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.
> 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.
I don't think we'll see a fork. There will be some gems that support rbx only and some that are MRI only and some that require jruby. However, seeing how things go with jruby I'd expect that most of the code stays runtime agnostic and people will use whatever runtime suits the current problem best. Given that there's a ruby spec now I imagine we'll end up pretty much where javascript is: Multiple runtimes that all support pretty much the same code. Or have a look at java or c, there's more than one jvm and with good reason as well as multiple c compilers that all produce working code :)
And yes, I do see heroku supporting both MRI and rbx as equals, but my point was that that's not replacing.
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.
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.
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.
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.
Fair enough. But I meant "fast" relative to Ruby 1.9.2, not "fast" relative to anything else. The "require" issue aside, REE beats out 1.9.2 pretty handily in a lot of real world situations. I've seen 1.9.2 win in microbenchmarks, but I haven't actually seen it perform better on a real app yet. Obvious selection bias there, but the point really being there's no compelling reason to upgrade.
Yes. Unfortunately, the balance seems heavily weighted toward the slow end of the curve, so that in practice it comes out slower than MRI.
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.)
Yeah, I agree. Lua is actually my favorite language ahead of Ruby. I have F3 mapped in Vim to run my tests; one of my projects is an implementation of Haml in Lua, and even that runs all of its tests in a small fraction of a second. The more you work with Lua the harder it can be to go back to Ruby sometimes.
I like Lua, but it does lack Ruby's elegance and expressiveness. Its best trait may be that it's simple, and therefore performant.
On my list of gripes: Lua's attempt at OO, being implemented as hash tables, is even more pitiful than JavaScript's. Also, arrays are implemented as hashes (just like PHP!), which is just one notch below JavaScript again. I also wish for a more expressive regex syntax, but then that's the text processing talking.
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.
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
It's hard to read that data because there's no label on the vertical axis. But through all the charts there, it looks like 1.8.7 is still the most widely deployed version. I'd imagine it'll remain that way for a while longer.
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.
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)
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.
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.
> 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.
Really? It seems to me like a mostly small vocal group is pushing 3. Most people I talk to actually using it heavily in production are ambivalent or actively planning on staying on 2.
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.
> 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.
All of that would have been acceptable, if they also implemented some major language fixes and adding some cool new features. Better closure support comes to mind...
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.
> 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.
