3 ms·

Almost all of the issues mentioned in this post were during 1.8 -> 1.9 transition. At that time odd release numbers where development versions, until this poli

by byroot 3y ago

Almost all of the issues mentioned in this post were during 1.8 -> 1.9 transition. At that time odd release numbers where development versions, until this policy changed a bit later and 1.9 became an actual "GA" release. The 1.8 -> 1.9 is really Ruby's "Python 3" moment, as it similarly improved String encoding handling, but the breakages were much more limited and it also came with pretty significant performance improvements, so the community didn't split like Python 2 and Python 3. If you follow Ruby's development, or watch Matz talks, you see that avoiding a Python like split is really his number 1 concern.

jrochkind1 3y ago
I agree with your analysis, as a rubyist since ruby 1.8. > but the breakages were much more limited and it also came with pretty significant performance improvements, so the community didn't split like Python 2 and Python 3. I think perhaps the ruby community was also smaller (or at least not TOO large), had an average higher level of skill (goes with the first, usually), and was fairly committed to ruby and/or rails at the time (we loved it, there were few if any similar alternatives). I agree that there hasn't been a similar level of backwards breaking since 1.8 => 1.9, and that if there were now it would be much more disastrous. Keyword arguments in ruby ~3.0 come closest, but still were much less disruptive than 1.8=>1.9. I have never been a serious python user, so can't really compare to python 2=>3, but my impression is that python 2=>3 was bigger even than ruby 1.8=>1.9. *BUT* that other typical python "minor" releases may actually have fewer backwards breaking changes than typical ruby "minor" releases?
- byroot 3y ago
  > I think perhaps the ruby community was also smaller Back in 2008-2010 when Python 3 was released, Python really wasn't as huge as it is today. It probably was bigger than Ruby, but not by that much. One datapoint (that doesn't give the full picture), Pycon 2008 had 1k attendees [0], Railsconf 1k8 [1]. IMO It's really in the early/mid 2010's with the rise of "big data" that the Python community really became huge compared to Ruby's. > I have never been a serious python user, so can't really compare As an ex-pythonista, now Rubyist, IMO one huge factor was that Python 2 and 3 were developed concurrently for several years, that played in the messaging. Python 3.0 was released on 2008, Python 2.7 in 2010, and Python 3 wasn't really deemed production ready until 3.2 or 3.3 if I remember correctly. So there was a 4-5 years limbo. Whereas in Ruby's case, it was very clear to the community that 1.9.x was the future. Also Python 3 did make some absolutely necessary breaking changes (like unicode), but also some minor syntax changes that made it much harder to support both with a single codebase for questionable gains. e.g. the `try/except`syntax was `except Class, var:` in 2.x, and `except Class as var:` in 3.x. That kind of changes made it hard for packages maintainers to support both versions. Ruby 1.9 didn't have this problem. It was much easier if not trivial to write code that worked on both Ruby 1.8 and 1.9. > typical python "minor" releases may actually have fewer backwards breaking changes than typical ruby "minor" releases? I haven't seriously used Python in a long time, but from occasionally glancing at release notes, they seem to regularly deprecate things. Can't say if more or less than Ruby. [0] https://pycon.blogspot.com/2008/04/part-2-attendance-registration-pycon.html https://pycon.blogspot.com/2008/04/part-2-attendance-registr... [1] https://www.endpointdev.com/blog/2008/06/railsconf-2008-report/ https://www.endpointdev.com/blog/2008/06/railsconf-2008-repo...
  - jrochkind1 3y ago
    > Ruby 1.9 didn't have this problem. It was much easier if not trivial to write code that worked on both Ruby 1.8 and 1.9. Oh yeah, that is hugely important, and I agree ruby does this; it's usually not hard to write code that will work on at least the last handful of ruby releases. The keyword arg changes initially made this difficult in one particular case -- and this was seen as a problem, so they introduced the `ruby2_keywords :method_name` thing, to make it possible with an opt-in to make sure you had identical behavior in all versions, before the ruby version was released that would have made it impossible.
  - formerly_proven 3y ago
    > I haven't seriously used Python in a long time, but from occasionally glancing at release notes, they seem to regularly deprecate things. The meaning of deprecation changed a bit. Before 3.6 or so things were deprecated, but just left in and maybe eventually removed when they broke for good, which would rarely happen. Nowadays deprecation means it will actually be removed after two releases (years), and a lot of stuff was deprecated basically just because it was old. I don't think that's an amazing signal to send, honestly.
- 0x457 3y ago
  Well, the most vocal ruby community was RoR users, while python even back then was used by multiple camps. Ruby done a smart upgrade path - new features in 2.x and breaking changes in 1.9.x. Ruby also got a "new" VM (it wasn't new, but it was the new default VM). Before 1.9.3 the best way to deploy ruby was Passenger with RubyEE. RubyEE was based on 1.8.7 and with all the improvements that the mainline ruby implementation got there was no reason to maintain RubyEE fork. The 2.0.0 release meant to be 100% compatible with 1.9.3 and had ABI version 1.9.1. Also, prior 2.1.0 Ruby used versioning very different from SemVer, hence 1.9.x had multiple breaking changes in its lifetime. It didn't mean "patch" version back then. I think the main difference is that the newer ruby was actually faster than the older ruby and gave plenty of reasons to move. The main pain point im ruby migration was that it became encoding aware. Python 3 wasn't as lucky.

by byroot 3y ago

jrochkind1 3y ago

I agree with your analysis, as a rubyist since ruby 1.8. > but the breakages were much more limited and it also came with pretty significant performance improvements, so the community didn't split like Python 2 and Python 3. I think perhaps the ruby community was also smaller (or at least not TOO large), had an average higher level of skill (goes with the first, usually), and was fairly committed to ruby and/or rails at the time (we loved it, there were few if any similar alternatives). I agree that there hasn't been a similar level of backwards breaking since 1.8 => 1.9, and that if there were now it would be much more disastrous. Keyword arguments in ruby ~3.0 come closest, but still were much less disruptive than 1.8=>1.9. I have never been a serious python user, so can't really compare to python 2=>3, but my impression is that python 2=>3 was bigger even than ruby 1.8=>1.9. *BUT* that other typical python "minor" releases may actually have fewer backwards breaking changes than typical ruby "minor" releases?

byroot 3y ago
> I think perhaps the ruby community was also smaller Back in 2008-2010 when Python 3 was released, Python really wasn't as huge as it is today. It probably was bigger than Ruby, but not by that much. One datapoint (that doesn't give the full picture), Pycon 2008 had 1k attendees [0], Railsconf 1k8 [1]. IMO It's really in the early/mid 2010's with the rise of "big data" that the Python community really became huge compared to Ruby's. > I have never been a serious python user, so can't really compare As an ex-pythonista, now Rubyist, IMO one huge factor was that Python 2 and 3 were developed concurrently for several years, that played in the messaging. Python 3.0 was released on 2008, Python 2.7 in 2010, and Python 3 wasn't really deemed production ready until 3.2 or 3.3 if I remember correctly. So there was a 4-5 years limbo. Whereas in Ruby's case, it was very clear to the community that 1.9.x was the future. Also Python 3 did make some absolutely necessary breaking changes (like unicode), but also some minor syntax changes that made it much harder to support both with a single codebase for questionable gains. e.g. the `try/except`syntax was `except Class, var:` in 2.x, and `except Class as var:` in 3.x. That kind of changes made it hard for packages maintainers to support both versions. Ruby 1.9 didn't have this problem. It was much easier if not trivial to write code that worked on both Ruby 1.8 and 1.9. > typical python "minor" releases may actually have fewer backwards breaking changes than typical ruby "minor" releases? I haven't seriously used Python in a long time, but from occasionally glancing at release notes, they seem to regularly deprecate things. Can't say if more or less than Ruby. [0] https://pycon.blogspot.com/2008/04/part-2-attendance-registration-pycon.html https://pycon.blogspot.com/2008/04/part-2-attendance-registr... [1] https://www.endpointdev.com/blog/2008/06/railsconf-2008-report/ https://www.endpointdev.com/blog/2008/06/railsconf-2008-repo...
- jrochkind1 3y ago
  > Ruby 1.9 didn't have this problem. It was much easier if not trivial to write code that worked on both Ruby 1.8 and 1.9. Oh yeah, that is hugely important, and I agree ruby does this; it's usually not hard to write code that will work on at least the last handful of ruby releases. The keyword arg changes initially made this difficult in one particular case -- and this was seen as a problem, so they introduced the `ruby2_keywords :method_name` thing, to make it possible with an opt-in to make sure you had identical behavior in all versions, before the ruby version was released that would have made it impossible.
- formerly_proven 3y ago
  > I haven't seriously used Python in a long time, but from occasionally glancing at release notes, they seem to regularly deprecate things. The meaning of deprecation changed a bit. Before 3.6 or so things were deprecated, but just left in and maybe eventually removed when they broke for good, which would rarely happen. Nowadays deprecation means it will actually be removed after two releases (years), and a lot of stuff was deprecated basically just because it was old. I don't think that's an amazing signal to send, honestly.
0x457 3y ago
Well, the most vocal ruby community was RoR users, while python even back then was used by multiple camps. Ruby done a smart upgrade path - new features in 2.x and breaking changes in 1.9.x. Ruby also got a "new" VM (it wasn't new, but it was the new default VM). Before 1.9.3 the best way to deploy ruby was Passenger with RubyEE. RubyEE was based on 1.8.7 and with all the improvements that the mainline ruby implementation got there was no reason to maintain RubyEE fork. The 2.0.0 release meant to be 100% compatible with 1.9.3 and had ABI version 1.9.1. Also, prior 2.1.0 Ruby used versioning very different from SemVer, hence 1.9.x had multiple breaking changes in its lifetime. It didn't mean "patch" version back then. I think the main difference is that the newer ruby was actually faster than the older ruby and gave plenty of reasons to move. The main pain point im ruby migration was that it became encoding aware. Python 3 wasn't as lucky.