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

What's New in Ruby 2.1 [pdf]

atdot.net

Post reply on HN
Print view View original

21–30 of 36 posts

Re: What's New in Ruby 2.1 [pdf]

#21

Post by bct »

Slackwise wrote: post #14

I'm uncertain why they've added an `f` suffix for frozen string literals/instantiation. I can understand needing to freeze an existing String, but you can do that with Object#freeze, but a literal syntax seems to overlap with the usage of Symbols. The only benefit I can think of is not needing to use Symbol#to_s when working alongside strings. I'm not saying frozen strings are not useful, because they can be after ta…

My understanding is that frozen strings (unlike Symbols) are garbage collected. This is useful because symbol construction can be used to DOS an application.

(I agree that it's a weird, low level detail to have to think about.)

Re: What's New in Ruby 2.1 [pdf]

#22

Post by andyl »

I've upgraded one of my Rails4 apps to 2.1.0-preview2. Everything seems to be working fine except pry-debugger.

What is it with the ruby debugger? It has always been problematic for me.

Re: What's New in Ruby 2.1 [pdf]

#24

Post by Slackwise »

jhawthorn wrote: post #19
Slackwise wrote: post #14

I'm uncertain why they've added an `f` suffix for frozen string literals/instantiation. I can understand needing to freeze an existing String, but you can do that with Object#freeze, but a literal syntax seems to overlap with the usage of Symbols. The only benefit I can think of is not needing to use Symbol#to_s when working alongside strings. I'm not saying frozen strings are not useful, because they can be after ta…

The f suffix has been removed in favour of the existing "foo".freeze (which is now recognized and optimized in the parser) https://www.ruby-lang.org/en/news/2013/11/22/ruby-2-1-0-prev... https://bugs.ruby-lang.org/issues/9042

That clears up the semantic similarity issue for me nicely. Having them as a literal was too awkward, and honestly, pretty ugly.

Thanks for the heads-up!

Re: What's New in Ruby 2.1 [pdf]

#27

Post by steveklabnik »

danso wrote: post #8

Everytime I read a Ruby version announcement/explanation, it reminds me that I've been a coder working and thinking exclusively in English, but my current programming language of choice is prominently steered by non-English speakers...and somehow things work pretty peachy. But it always makes me wonder how much more in-depth and richer the discussion of Ruby amongst its Japanese maintainers, before they translate it…

You can subscribe to ruby-dev and find out. ;) It's actually much more low-traffic than ruby-core, and someone has volunteered to translate any email if you ask.

Re: What's New in Ruby 2.1 [pdf]

#28

Post by derefr »

bct wrote: post #21
Slackwise wrote: post #14

I'm uncertain why they've added an `f` suffix for frozen string literals/instantiation. I can understand needing to freeze an existing String, but you can do that with Object#freeze, but a literal syntax seems to overlap with the usage of Symbols. The only benefit I can think of is not needing to use Symbol#to_s when working alongside strings. I'm not saying frozen strings are not useful, because they can be after ta…

My understanding is that frozen strings (unlike Symbols) are garbage collected. This is useful because symbol construction can be used to DOS an application. (I agree that it's a weird, low level detail to have to think about.)

Wait, so Ruby has the same problem with symbols that Erlang does with atoms? Why don't I constantly see warnings against using String#intern the way I do about list_to_atom/1?

Re: What's New in Ruby 2.1 [pdf]

#29

Post by thedevelopment »

andyl wrote: post #22

I've upgraded one of my Rails4 apps to 2.1.0-preview2. Everything seems to be working fine except pry-debugger. What is it with the ruby debugger? It has always been problematic for me.

I believe the debugger is broken in Ruby-2.0, and you should use byebug instead.

There are pry wrappers for byebug - https://github.com/deivid-rodriguez/pry-byebug - maybe that'll work?

Re: What's New in Ruby 2.1 [pdf]

#30

Post by matsadler »

dylandrop wrote: post #11

Can someone explain the "write barrier" stuff? It's hard to glean what the problem is that they're solving here... And what they're saying about Arrays, Strings, Hash, etc, in relation to WB protected vs. WB unprotected.

I've not read the code, so someone may have to correct me, but I think this is the gist of it:

Ruby 2.1 introduces a generational garbage collector, this divides all objects into young and old generations. A regular GC run will only look at the young generation, with the old being collected less frequently. An object is promoted to the old generation when it survives a young generation run.

If you have objects in the old generation referring objects in the young generation, but you're only looking at the young generation it may seem like an object doesn't have any references, and you might incorrectly GC an in-use object. Write barriers prevent this by adding old generation objects to a 'remember set' when they are modified to refer to a young generation object (eg old_array.push(young_string)). This 'remember set' is then taken in to account when collecting the young generation.

Most generational garbage collectors need these write barriers on all objects, but with the many 3rd party C extensions available for Ruby this isn't possible, so a workaround was devised whereby objects that aren't write barrier protected won't ever be promoted to the old generation. This isn't ideal as you won't get the full benefit of the generational GC, but it does maximise backwards compatibility.

Post reply on HN