41–50 of 62 posts
Earlier quoted context omitted.
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?
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/...
I wish overall performance was on that list!
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.
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".
> 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…
Earlier quoted context omitted.
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.
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
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...
Earlier quoted context omitted.
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.
Most of the large apps in production I'm aware of have just stuck with 1.8. It's stable and fast.
Earlier quoted context omitted.
> 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…
I think we're going to see a fork in the community, and I think heroku will end up supporting both MRI and rbx as equals.
And yes, I do see heroku supporting both MRI and rbx as equals, but my point was that that's not replacing.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
But you have noticed that MacRuby is an MRI fork?
Yes. What's your point?
(note: I'm not following MacRuby Development very closely at the moment.)
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.
But I don't think that Evan, Brian, et al.'s goals have been to replace but rather further the movement of Ruby.