change in Ruby 1.9, which moved Strings from "bags of bytes" to codepoints with tagged encoding, which means good UTF-8 support 5/
-
-
Replying to @wycats
the difference is that Ruby did a lot to keep the new String compatible with old String (BINARY encoding and compat hax for just-ASCII 6/
1 reply 1 retweet 2 likes -
Replying to @wycats
Strings), which meant a decent amount of encoding weirdness for a little bit, but, in the long-term, a smooth-enough transition. 7/
1 reply 0 retweets 2 likes -
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 -
yes, whereas python 3 got a bit slower.
1 reply 0 retweets 0 likes
yeah
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.