6 ms·

It's fascinating to compare this with ruby 1.9, released around the same time, but seemingly with a slightly better cost/benefit ratio, having nice new features

by themgt 13y ago

It's fascinating to compare this with ruby 1.9, released around the same time, but seemingly with a slightly better cost/benefit ratio, having nice new features and also significantly improved performance, and with ruby 1.8 being deprecated with a lot more speed and force. It got everyone to actually make the switch, and then ruby 2.0 came along, largely compatible and with a more improvements, and now ruby 2.1 seems to be an even smoother upgrade from 2.0. The ability of the ruby core team to manage not just the technical aspect of making the language better, but smooth the transition in a way that actually succeeded in bringing the community (and even alternate ruby implementations) along with them, hasn't been given nearly enough credit. You could analogize it to Apple with OS 9 -> OS 10.9, versus Microsoft with people still running XP

steveklabnik 13y ago
Matz has also said no breaking changes until ruby 3.0, which is 'ten years away.' I don't expect this to actually be true, but it speaks to an attitude.
- UNIXgod 13y ago
  If he said it I believe it. I don't worry so much about Matz and the Ruby core committers breaking things.
  - jrochkind1 13y ago
    Well, i mean, there were backwards incompat changes in ruby 2.0, which I think is after he said there woudln't be. They were fairly minor and easily dealt with, but there was certainly some software that had to be adjusted for ruby 2.0 from 1.9.3. https://gist.github.com/nathany/6046171 https://gist.github.com/nathany/6046171
- cies 13y ago
  i feel ruby's syntax is mostly done. an addition here or there, but breaking shall be rare as it just feels so finished. performance wise i think it can use (and gets) a lot of love. on the python side things are different. python seems quite a bit faster then ruby. same league, but faster. yet its syntax is what needs to be greatly improved upon as it is so full of surprises and dark corners. a language's syntax it's like its API, and performance is an implementation "detail". breaking the API is much more painful then chaning the implementation -- therefor i prefer ruby's approach: begin slow but with a quite stable syntax. p.s. i dont intend to hurt feelings with this comment
  - anonova 13y ago
    In synthetic benchmarks, Ruby 2.0 is generally faster or approximately equal to that of Python 3. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=python3&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
- cstejerean 13y ago
  I've seen breaking changes between Ruby 1.8.6 and 1.8.7, so I'm really suspicious of this claim. Start with which version of Ruby are breaking changes not to be expected until 3.0?
  - steveklabnik 13y ago
    From 2.0 -> 3.0. Ruby doesn't follow SemVer, so expecting no breaking changes between 1.8.6 and 1.8.7 wouldn't necessarily be correct. I don't remember what the policy was at the time.
    - zefhous 13y ago
      BTW, it was just announced that Ruby will use SemVer starting from Ruby 2.1.0. https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ https://www.ruby-lang.org/en/news/2013/12/21/semantic-versio...
      - steveklabnik 13y ago
        Excellent, thank you. I missed that during the holidays.
      - nona 13y ago
        > MINOR: Increase at each December 25th; may be API incompatible Well now, that's not exactly semver, is it…?
    - lentil 13y ago
      FWIW, it's starting to do so now: https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ https://www.ruby-lang.org/en/news/2013/12/21/semantic-versio...
w1ntermute 13y ago
> You could analogize it to Apple with OS 9 -> OS 10.9, versus Microsoft with people still running XP No, you couldn't. The difference in upgrade rates between Windows and OS X is primarily due to their differing customer bases. Windows is very popular in enterprise, which avoids unnecessary upgrades in order to ensure compatibility with in-house software. OS X, however, has almost no presence in enterprise, and consumers don't mind upgrades nearly as much, since the consumer software they use has to be compatible with all OS versions. Also, you can't buy Macs with old versions of OS X, whereas Microsoft makes it trivial to buy a new machine and install an older version of Windows.
- jshen 13y ago
  Mags have a significant presence in enterprise these days.
  - ghaff 13y ago
    Yes, Macs have a decent presence in enterprises these days--although it's easy to overstate it; Mac overall market share is still pretty low. Somewhere in the 10% percent range I believe. Furthermore. and to the original point, a lot of those Macs are BYOD or otherwise not managed as a corporate desktop/laptop. (Where I work is a case in point. You see a fair number of Macs but IT doesn't formally support them.)
    - laureny 13y ago
      > Mac overall market share is still pretty low. Somewhere in the 10% percent range I believe. That's in the US. In the rest of the world, it's around 5%.
      - w1ntermute 13y ago
        According to this site[0], it's at 7.54%. Out of that, only 32% are running the latest version of OS X (10.9). Another 24.5% are running 10.8. So almost half of OS X users are at least 2 versions behind. Not nearly as up-to-date as you might think. 0: http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 http://www.netmarketshare.com/operating-system-market-share....
danso 13y ago
But were the changes between 1.8 and 1.9 in Ruby as significant as 2 to 3 to Python? Or even 1.8 to 2.0? I know in Ruby 1.8.x to 1.9, some major changes in my day-to-day coding involved Hash (elimination of hash-rocket, and ordered key-value pairs by default)...but I can't think of anything off hand that required me to rewrite my own libraries. And between 1.9 and 2.0...I've been switching between machines that have 1.9.3x and 2.0x and can't even tell a difference. Obviously, I'm not doing any legacy-maintenance in this situation, but it seemed that Python's changes, while breaking, were also significant improvements and changes to the API that mandated changes in implementation? Speaking as a non-Python-dev...I've been wanting to get more into Python, at least to write routines that take advantage of scipy and numpy and all that goodness...but the process of deciding between 2.x and 3.x and keeping the steps/compromises in order can be beguiling.
- dragonwriter 13y ago
  > but I can't think of anything off hand that required me to rewrite my own libraries. There were a lot of gems that weren't 1.9 compatible for quite a while, so there must have been something that caused people to rewrite libraries. I think that one disadvantage for Python 2->3 was an advantage Python had over Ruby -- the bigger base of libraries, many of which were widely used but basically in very-low-effort maintenance mode.
- wycats 13y ago
  1.8 to 1.9 was a HUGE release in terms of breaking changes. Probably the most notable change was the introduction of proper unicode support. Unlike Python, which changed syntax at the same time, Ruby tried to maintain compatibility with existing syntax. In practice, this allowed Ruby libraries (including Rails; I did the bulk of the encoding work for Ruby 1.9 in Rails 3) to do runtime introspection to support 1.8 and 1.9 at the same time. In my view, the best, most underrated thing that Matz did in Ruby 1.9 was to make all of the breaking changes detectable and shimmable at runtime.
  - danso 13y ago
    Ah yes, it's fitting that I would forget about the Unicode change...the fact that I did so is just further affirmation of why I still get myself into encoding problems...all the time. But yes, the Unicode support did seem to be a frequent reason for library overhauls.

by themgt 13y ago

steveklabnik 13y ago

Matz has also said no breaking changes until ruby 3.0, which is 'ten years away.' I don't expect this to actually be true, but it speaks to an attitude.

UNIXgod 13y ago
If he said it I believe it. I don't worry so much about Matz and the Ruby core committers breaking things.
- jrochkind1 13y ago
  Well, i mean, there were backwards incompat changes in ruby 2.0, which I think is after he said there woudln't be. They were fairly minor and easily dealt with, but there was certainly some software that had to be adjusted for ruby 2.0 from 1.9.3. https://gist.github.com/nathany/6046171 https://gist.github.com/nathany/6046171
cies 13y ago
i feel ruby's syntax is mostly done. an addition here or there, but breaking shall be rare as it just feels so finished. performance wise i think it can use (and gets) a lot of love. on the python side things are different. python seems quite a bit faster then ruby. same league, but faster. yet its syntax is what needs to be greatly improved upon as it is so full of surprises and dark corners. a language's syntax it's like its API, and performance is an implementation "detail". breaking the API is much more painful then chaning the implementation -- therefor i prefer ruby's approach: begin slow but with a quite stable syntax. p.s. i dont intend to hurt feelings with this comment
- anonova 13y ago
  In synthetic benchmarks, Ruby 2.0 is generally faster or approximately equal to that of Python 3. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=python3&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
cstejerean 13y ago
I've seen breaking changes between Ruby 1.8.6 and 1.8.7, so I'm really suspicious of this claim. Start with which version of Ruby are breaking changes not to be expected until 3.0?
- steveklabnik 13y ago
  From 2.0 -> 3.0. Ruby doesn't follow SemVer, so expecting no breaking changes between 1.8.6 and 1.8.7 wouldn't necessarily be correct. I don't remember what the policy was at the time.
  - zefhous 13y ago
    BTW, it was just announced that Ruby will use SemVer starting from Ruby 2.1.0. https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ https://www.ruby-lang.org/en/news/2013/12/21/semantic-versio...
    - steveklabnik 13y ago
      Excellent, thank you. I missed that during the holidays.
    - nona 13y ago
      > MINOR: Increase at each December 25th; may be API incompatible Well now, that's not exactly semver, is it…?
  - lentil 13y ago
    FWIW, it's starting to do so now: https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ https://www.ruby-lang.org/en/news/2013/12/21/semantic-versio...

w1ntermute 13y ago

> You could analogize it to Apple with OS 9 -> OS 10.9, versus Microsoft with people still running XP No, you couldn't. The difference in upgrade rates between Windows and OS X is primarily due to their differing customer bases. Windows is very popular in enterprise, which avoids unnecessary upgrades in order to ensure compatibility with in-house software. OS X, however, has almost no presence in enterprise, and consumers don't mind upgrades nearly as much, since the consumer software they use has to be compatible with all OS versions. Also, you can't buy Macs with old versions of OS X, whereas Microsoft makes it trivial to buy a new machine and install an older version of Windows.

jshen 13y ago
Mags have a significant presence in enterprise these days.
- ghaff 13y ago
  Yes, Macs have a decent presence in enterprises these days--although it's easy to overstate it; Mac overall market share is still pretty low. Somewhere in the 10% percent range I believe. Furthermore. and to the original point, a lot of those Macs are BYOD or otherwise not managed as a corporate desktop/laptop. (Where I work is a case in point. You see a fair number of Macs but IT doesn't formally support them.)
  - laureny 13y ago
    > Mac overall market share is still pretty low. Somewhere in the 10% percent range I believe. That's in the US. In the rest of the world, it's around 5%.
    - w1ntermute 13y ago
      According to this site[0], it's at 7.54%. Out of that, only 32% are running the latest version of OS X (10.9). Another 24.5% are running 10.8. So almost half of OS X users are at least 2 versions behind. Not nearly as up-to-date as you might think. 0: http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 http://www.netmarketshare.com/operating-system-market-share....

danso 13y ago

But were the changes between 1.8 and 1.9 in Ruby as significant as 2 to 3 to Python? Or even 1.8 to 2.0? I know in Ruby 1.8.x to 1.9, some major changes in my day-to-day coding involved Hash (elimination of hash-rocket, and ordered key-value pairs by default)...but I can't think of anything off hand that required me to rewrite my own libraries. And between 1.9 and 2.0...I've been switching between machines that have 1.9.3x and 2.0x and can't even tell a difference. Obviously, I'm not doing any legacy-maintenance in this situation, but it seemed that Python's changes, while breaking, were also significant improvements and changes to the API that mandated changes in implementation? Speaking as a non-Python-dev...I've been wanting to get more into Python, at least to write routines that take advantage of scipy and numpy and all that goodness...but the process of deciding between 2.x and 3.x and keeping the steps/compromises in order can be beguiling.

dragonwriter 13y ago
> but I can't think of anything off hand that required me to rewrite my own libraries. There were a lot of gems that weren't 1.9 compatible for quite a while, so there must have been something that caused people to rewrite libraries. I think that one disadvantage for Python 2->3 was an advantage Python had over Ruby -- the bigger base of libraries, many of which were widely used but basically in very-low-effort maintenance mode.
wycats 13y ago
1.8 to 1.9 was a HUGE release in terms of breaking changes. Probably the most notable change was the introduction of proper unicode support. Unlike Python, which changed syntax at the same time, Ruby tried to maintain compatibility with existing syntax. In practice, this allowed Ruby libraries (including Rails; I did the bulk of the encoding work for Ruby 1.9 in Rails 3) to do runtime introspection to support 1.8 and 1.9 at the same time. In my view, the best, most underrated thing that Matz did in Ruby 1.9 was to make all of the breaking changes detectable and shimmable at runtime.
- danso 13y ago
  Ah yes, it's fitting that I would forget about the Unicode change...the fact that I did so is just further affirmation of why I still get myself into encoding problems...all the time. But yes, the Unicode support did seem to be a frequent reason for library overhauls.