Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 2.2.0 Released

ruby-lang.org

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Ruby 2.2.0 Released

#71

Post by wycats »

berdario wrote: post #32
matthewmacleod wrote: post #27

Earlier quoted context omitted.

What situation is that, out of interest? As of Ruby 1.9, there's a pretty sensible solution to this in the language, and I haven't had any encoding problems in some time. I appreciate I might have missed something though!

(I'll try to keep this short, since I feel this is quite offtopic, if we want to discuss this further I suppose we could find a better venue... maybe even email?) I assume that with "Ruby 1.9 solution", you refer to the fact that Ruby source code is by default evaluated as UTF-8, right? That's definitely a good thing, but with Python3 that wasn't the only change brought into the language. I said "if Ruby ever decides…

The primary difference between Ruby and Python, from where I'm sitting, is that Ruby's change was purely at the API level, so it was feature-detectable and shimmable by libraries like Rails. I talk elsewhere in this thread about the effort we had to do, but the point is, we could do it.

In contrast, Python 3 changed the meaning of "foo". It also supported only u"foo" in Python 2 (to opt-in to unicode strings) and only b"foo" in Python 3 (to opt-in to byte-strings) for a fairly long period of time, making it extremely, extremely awkward (at best) to write a program with shims as abstractions that let most of the program remain oblivious to the differences.

Python 3.3 and 2.7 finally landed a lot of fixes to this kind of problem, but it landed fairly late, and after most of the community got a sense of the relative difficulty level of a transition to Python 3 that maintained support for Python 2 at the same time.

Both Ruby and JavaScript have taught me the value of a transition path to a new version that allows people to write libraries that support both the old and new version at the same time. Communities move a little at a time, especially long-term production projects. The best way to move them is via libraries that can serve as a bridge and target both the old and new version together.

Re: Ruby 2.2.0 Released

#72

Post by wycats »

wycats wrote: post #68
Xylakant wrote: post #64

Earlier quoted context omitted.

Han unification is the primary reason not to force utf8, especially in a language that has strong roots in Japan. (Sorry to be short, I'm on a smartphone. Googling should provide sufficient answers)

Han unification is one problem; another problem is that not all encodings can be round-tripped losslessly through Unicode. Shift-JIS, for example, has multiple separate characters that convert into the same character in Unicode, and therefore cannot be converted back into their original form reliably.

Citation: http://support.microsoft.com/kb/170559

Re: Ruby 2.2.0 Released

#74

Post by MichaelGG »

Xylakant wrote: post #64
MichaelGG wrote: post #58

Earlier quoted context omitted.

Excuse my density here, but why not just force all strings to be UTF8 and call it a day? Anything in another encoding would need to get converted. What am I missing that Ruby and Python need these complicated problems but other platforms don't have these issues?

Han unification is the primary reason not to force utf8, especially in a language that has strong roots in Japan. (Sorry to be short, I'm on a smartphone. Googling should provide sufficient answers)

Wow. That's pretty ugly, thanks for the info. But for people not wanting to use Unicode... Does that not mean they simply cannot use strings in Java, .Net, Windows (to some extent), etc.? It just seems sorta not feasible at this point to not use Unicode. And according to Wikipedia, Unicode now has a way to select which language variant of a unified character. So is unification not as big a problem if people use selectors?

And what's the practical alternative? Keeping things in country specific encodings?

Re: Ruby 2.2.0 Released

#75

Post by cmelbye »

grandalf wrote: post #73
cmelbye wrote: post #67

Not compatible with Rails 3.2.x, for those still on that version. (And possibly will never be, as 3.2.x only receives security updates now.)

What is the nature of the incompatibility?

One change is that test/unit is now no longer part of the standard library, which Rails requires. The workaround is simple, "test-unit" must be added to the Gemfile.

A less easily fixed change is that the following syntax no longer works the same as it did in previous versions of Ruby:

    def foo(bar = bar)
The recommended fix is the following: (I believe)

    def foo(bar = bar())
Rails uses this syntax occasionally. It's simple to change, but the Rails team refuses to merge in the fixes because it's not a security issue.

Re: Ruby 2.2.0 Released

#76

Post by MichaelGG »

wycats wrote: post #68
Xylakant wrote: post #64

Earlier quoted context omitted.

Han unification is the primary reason not to force utf8, especially in a language that has strong roots in Japan. (Sorry to be short, I'm on a smartphone. Googling should provide sufficient answers)

Han unification is one problem; another problem is that not all encodings can be round-tripped losslessly through Unicode. Shift-JIS, for example, has multiple separate characters that convert into the same character in Unicode, and therefore cannot be converted back into their original form reliably.

The shift JIS issue seems to be a fault in the design of shift JIS, resulting in even symbols like square root not having a canonical encoding. At what point do you just draw the line and tell developers if they need to deal with such things themselves? No one is taking away byte arrays. Fragmenting the userbase seems suboptimal.

Re: Ruby 2.2.0 Released

#78

Post by [deleted] »

weaksauce wrote: post #51
jrochkind1 wrote: post #37

Earlier quoted context omitted.

Interesting, I haven't worked in python, but I was always jealous of python having a single 'official' solution in virtualenv, instead of ruby, where it's confusing for newcomers to figure out which one they should be using (rvm? rbenv? chruby?), and each solution has it's annoyances and problems. I always thought it would be better if the community unified it's efforts behind one solution and made sure it was bug-fr…

Since you haven't used it you don't know how awkward it is compared to the Ruby iterations. Let's just say virtualenv and the packaging ecosystem is what drew me away from Python.

[deleted]

Re: Ruby 2.2.0 Released

#79

Post by grandalf »

cmelbye wrote: post #75
grandalf wrote: post #73

Earlier quoted context omitted.

What is the nature of the incompatibility?

One change is that test/unit is now no longer part of the standard library, which Rails requires. The workaround is simple, "test-unit" must be added to the Gemfile. A less easily fixed change is that the following syntax no longer works the same as it did in previous versions of Ruby: def foo(bar = bar) The recommended fix is the following: (I believe) def foo(bar = bar()) Rails uses this syntax occasionally. It's s…

Wow that's too bad.

Do you know if the Rails team would approve a patch that was submitted?

Also, the change of the meaning of the right bar in your example above seems significant. Do you happen to know of any context for that change?

Re: Ruby 2.2.0 Released

#80

Post by pomartel »

arikrak wrote: post #38

Anyone know how Ruby 2.2 works with Rails on Heroku (with unicorn)? When I switched from 2.0 to 2.1, it caused all sorts of memory problems so I had to switch back.

I gave Ruby 2.2 a try with Rails 4.2 and the same memory problems that plagued Ruby 2.1 also occurred. I am switching back to Ruby 2.0. Rails 5 will require Ruby 2.2 and higher so I hope someone will find a way to fix this.
Post reply on HN