Strings), which meant a decent amount of encoding weirdness for a little bit, but, in the long-term, a smooth-enough transition. 7/
-
-
Replying to @wycats
The summary of the difference is this: In Ruby, it was possible to write a full shim library that worked in both 1.8 and 1.9 for 8/
2 replies 1 retweet 1 like -
Replying to @wycats
everything that we needed in Rails (I wrote a large amount of it and did a lot of the encoding work in Rails 3). In contrast, Py3.0 9/
1 reply 1 retweet 2 likes -
Replying to @wycats
shipped syntactic changes that were mutually exclusive with Py2.x. This made it impossible for Django to use the shim approach we 10/
1 reply 0 retweets 3 likes -
Replying to @wycats
used in Rails, and which got us on the "latest Ruby" train literally as early as was plausible. If you want to disagree with this 11/
1 reply 2 retweets 4 likes -
Replying to @wycats
analysis, you need to find an explanation for the wide difference in OUTCOMES between Py3 and Ruby1.9. Again, encodings ain't it. 12/12
8 replies 0 retweets 7 likes -
Replying to @wycats
1.9 also shipped with *huge* perf improvements over 1.8, which provided a strong incentive to upgrade. It was still kind of painful.
2 replies 0 retweets 3 likes -
Replying to @mwylde
it was painful but reducing the pain was an intentional and concerted effort (I was part of it), including reverting some 1/
1 reply 0 retweets 0 likes -
"necessary" breaking changes once they caused too much upgrade problems. 2/2
1 reply 0 retweets 0 likes -
Replying to @wycats
That definitely helped. But the carrot-and-stick approach of tying in YARV convinced a lot of people to do the work.
3 replies 0 retweets 0 likes
right, and Py3k choosing to be slower at first definitely didn't help.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.