7 ms·

Work has started on Ruby 2.0

80 points by ben_hall 15y ago

terhechte 15y ago
Let's hope it will gain more acceptance and usage than Python3. Do they intend major changes?
- pdelgallego 15y ago
  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
  - lloeki 15y ago
    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/ http://python3wos.appspot.com/ 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)
    - TylerE 15y ago
      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.
      - dextorious 15y ago
        > 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...
    - grifaton 15y ago
      Just minutes ago, this was announced on the Twisted mailing list: https://bitbucket.org/pitrou/t3k/wiki/Home https://bitbucket.org/pitrou/t3k/wiki/Home It's described as "an experimental, work-in-progress port of Twisted to Python 3".
    - jnoller 15y ago
      If you would like more resources than the FUD laden wall of shame, feel free to visit: http://getpython3.com/ 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.
      - dextorious 15y ago
        > The timeline for Python 3 adoption was always measured in years - not one, not two, but more. Already a lot of YEARS have passed, not one, not two, but more. We're even in 3.2 for heaven's sake. > Django has a Python 3 roadmap Yeah, has had one for years. How is that going? > The reports of death are grossly overstated. The reports of movement in this front are grossly overstated too.
    - holdenweb 15y ago
      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.
    - briancurtin 15y ago
      > 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.
  - jeremykemper 15y ago
    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-ruby-on-rails-benchmarking-report-sept-2011/ http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-rub...
    - nirvdrum 15y ago
      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.
- petercooper 15y ago
  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.
- Argorak 15y ago
  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.
  - dextorious 15y ago
    > 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.
plq 15y ago
That sounds nice but, what's the plan? The closest I could find was this: http://redmine.ruby-lang.org/projects/ruby-20/roadmap http://redmine.ruby-lang.org/projects/ruby-20/roadmap
- Argorak 15y ago
  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.
pdelgallego 15y ago
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/39810 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/...
- mjbellantoni 15y ago
  I wish overall performance was on that list!
  - petercooper 15y ago
    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-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang...
    - mjbellantoni 15y ago
      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.)
      - petercooper 15y ago
        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 ;-)
jkjeldgaard 15y ago
I can highly recommend Matz talk from RubyConf 2011, where he talks about the future of Ruby. http://confreaks.net/videos/654-rubyconf2011-keynote-ruby-everywhere http://confreaks.net/videos/654-rubyconf2011-keynote-ruby-ev...
compay 15y ago
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.
- Argorak 15y ago
  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.
  - compay 15y ago
    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.
    - Argorak 15y ago
      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.
      - compay 15y ago
        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.
        15y ago

80 points by ben_hall 15y ago

terhechte 15y ago

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

pdelgallego 15y ago
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
- lloeki 15y ago
  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/ http://python3wos.appspot.com/ 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)
  - TylerE 15y ago
    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.
    - dextorious 15y ago
      > 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...
  - grifaton 15y ago
    Just minutes ago, this was announced on the Twisted mailing list: https://bitbucket.org/pitrou/t3k/wiki/Home https://bitbucket.org/pitrou/t3k/wiki/Home It's described as "an experimental, work-in-progress port of Twisted to Python 3".
  - jnoller 15y ago
    If you would like more resources than the FUD laden wall of shame, feel free to visit: http://getpython3.com/ 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.
    - dextorious 15y ago
      > The timeline for Python 3 adoption was always measured in years - not one, not two, but more. Already a lot of YEARS have passed, not one, not two, but more. We're even in 3.2 for heaven's sake. > Django has a Python 3 roadmap Yeah, has had one for years. How is that going? > The reports of death are grossly overstated. The reports of movement in this front are grossly overstated too.
  - holdenweb 15y ago
    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.
  - briancurtin 15y ago
    > 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.
- jeremykemper 15y ago
  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-ruby-on-rails-benchmarking-report-sept-2011/ http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-rub...
  - nirvdrum 15y ago
    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.
petercooper 15y ago
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.
Argorak 15y ago
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.
- dextorious 15y ago
  > 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.

plq 15y ago

That sounds nice but, what's the plan? The closest I could find was this: http://redmine.ruby-lang.org/projects/ruby-20/roadmap http://redmine.ruby-lang.org/projects/ruby-20/roadmap

Argorak 15y ago
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.

pdelgallego 15y ago

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/39810 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/...

mjbellantoni 15y ago
I wish overall performance was on that list!
- petercooper 15y ago
  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-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang...
  - mjbellantoni 15y ago
    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.)
    - petercooper 15y ago
      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 ;-)

jkjeldgaard 15y ago

I can highly recommend Matz talk from RubyConf 2011, where he talks about the future of Ruby. http://confreaks.net/videos/654-rubyconf2011-keynote-ruby-everywhere http://confreaks.net/videos/654-rubyconf2011-keynote-ruby-ev...

compay 15y ago

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.

Argorak 15y ago
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.
- compay 15y ago
  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.
  - Argorak 15y ago
    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.
    - compay 15y ago
      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.
      - 15y ago