6 ms·

As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.

deleted 3y ago
[deleted]
fny 3y ago
But it was done slowly enough not to piss anyone off.
- tonyedgecombe 3y ago
  The transition to Python 3 took a very long time. I often wonder if they would have saved themselves a ton of grief if they had done it quicker.
  - 0x457 3y ago
    That's not what they meant. Ruby made breaking change by breaking change, and it was still easy to have gems work with both ABI versions. Python 3 had changes that made it necessary challenging to support both, all while being slower (IIRC).
formerly_proven 3y ago
Ruby is used a lot less so the base population of people able to complain is much smaller.
- peteforde 3y ago
  It's used less but those who use it mysteriously make a lot more money. I know which group I'm happy to be a part of.
multiplegeorges 3y ago
I had the opposite conclusion. This seems like a pretty minimal set of changes to get a 19 year old piece of software running.
- shellac 3y ago
  Ditto. Having had to update python code over the years, this looked much easier than python migrations. To be honest moving earlier python 3.x code to current 3.x is comparable, so good job ruby devs.
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...
halostatue 3y ago
Ruby has had two major backwards-incompatible change inflections: 1.9 and 3.0 (although I think that most of the removals were actually in 3.1). The painful one is 1.8–>1.9, because that's where Ruby's string grew encoding awareness. Going from 2.7->3.0 was not nearly as painful (mostly dealing with warnings and some code being removed from the standard library as gems that people can use if they want). I still maintain code that is nominally 1.8 compatible and it works just fine on 3.2 (I haven't yet tested on 3.3). What is surprising about this exercise is how little code needed to be changed on code designed for Ruby 1.8 to allow it to run on Ruby 3.3. The author doesn't say how long they spent on this, but it looks like 3–4 hours for a fairly complex piece of infrastructure code. How much effort would be required to run Django 1.0 on Python 3.12? At least this much, I’m sure. I suspect more, but I don't know the 2->3 differences well enough to be able to estimate that.
- herbst 3y ago
  This so much. In the first part my my work carrier I was fixing old PHP applications, nobody ever bothered to even mention software updates. The next part, in a ruby shop, was different. We would update all the software all the time, usually pretty painless or with one or two expected issues that are easily fixed. There was no point when it turned to old, every app was running the most recent rails and usually ruby just days after the release
JohnBooty 3y ago
Strongest possible disagree. There was some pain around Ruby 1.8->1.9 because of string encodings, but no huge schism ala Python 2/3. Did you experience both transitions or is that just your feeling based on this article? If anything, I think the article proves how relatively painless the transition was.
- buffington 3y ago
  I agree with your strong disagree. I know, and help maintain, Ruby code written for 1.8 that hasn't been touched and is running fine in 3.2. No breakage along the way. To be fair, that's not always possible, but Ruby's changes haven't ever been drastic. I've not had as much experience with Python as a programmer - more as a user of apps written in Python, and I sense there's a bigger issue there than Ruby has ever had. It seems like a frequent problem that something that works in Python 3 doesn't work with Python 2 and vice versa.
bdcravens 3y ago
From an outsider's perspective (I've written a little Python, but not enough that I consider myself a Pythonista) I didn't think it was backward incompatibility that was the problem as much as community libraries and frameworks not moving forward to v3 for a long time.
kshahkshah 3y ago
Hard disagree. For a moment there it wasn't clear if there was going to be a hard Python 2 vs 3 fork and people would literally refuse to migrate to 3. There was never such a moment in Ruby. The migrations from version to version were relatively smooth except 1.8.6 to 1.9 MRI -> YARV

deleted 3y ago

[deleted]

fny 3y ago

But it was done slowly enough not to piss anyone off.

tonyedgecombe 3y ago
The transition to Python 3 took a very long time. I often wonder if they would have saved themselves a ton of grief if they had done it quicker.
- 0x457 3y ago
  That's not what they meant. Ruby made breaking change by breaking change, and it was still easy to have gems work with both ABI versions. Python 3 had changes that made it necessary challenging to support both, all while being slower (IIRC).

formerly_proven 3y ago

Ruby is used a lot less so the base population of people able to complain is much smaller.

peteforde 3y ago
It's used less but those who use it mysteriously make a lot more money. I know which group I'm happy to be a part of.

multiplegeorges 3y ago

I had the opposite conclusion. This seems like a pretty minimal set of changes to get a 19 year old piece of software running.

shellac 3y ago
Ditto. Having had to update python code over the years, this looked much easier than python migrations. To be honest moving earlier python 3.x code to current 3.x is comparable, so good job ruby devs.

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...

halostatue 3y ago

Ruby has had two major backwards-incompatible change inflections: 1.9 and 3.0 (although I think that most of the removals were actually in 3.1). The painful one is 1.8–>1.9, because that's where Ruby's string grew encoding awareness. Going from 2.7->3.0 was not nearly as painful (mostly dealing with warnings and some code being removed from the standard library as gems that people can use if they want). I still maintain code that is nominally 1.8 compatible and it works just fine on 3.2 (I haven't yet tested on 3.3). What is surprising about this exercise is how little code needed to be changed on code designed for Ruby 1.8 to allow it to run on Ruby 3.3. The author doesn't say how long they spent on this, but it looks like 3–4 hours for a fairly complex piece of infrastructure code. How much effort would be required to run Django 1.0 on Python 3.12? At least this much, I’m sure. I suspect more, but I don't know the 2->3 differences well enough to be able to estimate that.

herbst 3y ago
This so much. In the first part my my work carrier I was fixing old PHP applications, nobody ever bothered to even mention software updates. The next part, in a ruby shop, was different. We would update all the software all the time, usually pretty painless or with one or two expected issues that are easily fixed. There was no point when it turned to old, every app was running the most recent rails and usually ruby just days after the release

JohnBooty 3y ago

Strongest possible disagree. There was some pain around Ruby 1.8->1.9 because of string encodings, but no huge schism ala Python 2/3. Did you experience both transitions or is that just your feeling based on this article? If anything, I think the article proves how relatively painless the transition was.

buffington 3y ago
I agree with your strong disagree. I know, and help maintain, Ruby code written for 1.8 that hasn't been touched and is running fine in 3.2. No breakage along the way. To be fair, that's not always possible, but Ruby's changes haven't ever been drastic. I've not had as much experience with Python as a programmer - more as a user of apps written in Python, and I sense there's a bigger issue there than Ruby has ever had. It seems like a frequent problem that something that works in Python 3 doesn't work with Python 2 and vice versa.

bdcravens 3y ago

From an outsider's perspective (I've written a little Python, but not enough that I consider myself a Pythonista) I didn't think it was backward incompatibility that was the problem as much as community libraries and frameworks not moving forward to v3 for a long time.

kshahkshah 3y ago

Hard disagree. For a moment there it wasn't clear if there was going to be a hard Python 2 vs 3 fork and people would literally refuse to migrate to 3. There was never such a moment in Ruby. The migrations from version to version were relatively smooth except 1.8.6 to 1.9 MRI -> YARV