
What's New in Ruby 2.1 [pdf] - gcv
http://www.atdot.net/~ko1/activities/toruby05-ko1.pdf
======
dylandrop
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.

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

------
danso
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 for us in English?

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

------
conorh
I really like the ObjectSpace.trace_object_allocations addition. I had a quick
look at the 2.1 docs for ObjectSpace and there seem to be all sorts of
interesting methods in there reachable_objects_from(obj) and memsize_of(obj)
for example. It looks like understanding memory usage and tracking down memory
leaks will get a lot easier with 2.1.

[http://ruby-doc.org/stdlib-2.1.0/libdoc/objspace/rdoc/Object...](http://ruby-
doc.org/stdlib-2.1.0/libdoc/objspace/rdoc/ObjectSpace.html#method-c-
trace_object_allocations)

~~~
matsadler
#reachable_objects_from was added in 2.0, and I think #memsize_of was
introduced in one of the 1.9 releases. The documentation is new though.

I wrote a little about them here:
[http://globaldev.co.uk/2013/03/ruby-2-0-0-in-
detail/#id6](http://globaldev.co.uk/2013/03/ruby-2-0-0-in-detail/#id6)

~~~
conorh
Ah nice, thanks, missed the part about requiring "objspace" to mix them in and
assumed they would be on the already existing ObjectSpace module.

------
thinkbohemian
Koichi is gives some of the best presentations. It is hard enough to be funny
in one language, yet to be funny and understandable in two is quite an
accomplishment. If you're ever at a Rubyconf, go to his talks. Also love the
speed work he's been doing with generational GC. For a primer, Pat Shaughnessy
has a great talk you should check out, also Ruby Under a Microscope is a good
dive into Ruby.

------
Slackwise
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 taking
in some input/params to work with/store, but a literal syntax seems extremely
edge-case-y. Now instead of "foo".freeze it's "foo"f, but how frequently will
that save you time/trouble?

The bigger implication is that slides 23/24 shows that immutable strings and
symbols will share their heap locations, if I'm reading the diagrams
correctly, but have different object_ids.

This seems a bit bewildering and focused on micro-optimization, which is not
the mental model I have in mind when I'm coding in a very high level language.
It's also blurring the semantic difference between Symbols and Strings.

~~~
jamesbritt
_Now instead of "foo".freeze it's "foo"f, but how frequently will that save
you time/trouble?_

Worse, it seems to break the model of "interact with objects by sending
messages", where you send a message using

    
    
        <object>.<message>
    

Is "foo"f _not_ sending a message? If so, then what is it doing? If yes, then
why new syntax?

~~~
bct
It's not sending a message - that would defeat the purpose. It's constructing
a frozen string, reusing an existing one when possible.

Prior to 2.1:

    
    
        def foo
          "bar".freeze
        end
    

does these things every time `foo` is called:

1\. copies the characters 'b', 'a', and 'r' into a mutable string

2\. sends the message `freeze` to the new string, which...

3\. marks the string as frozen.

In 2.1 `"bar".freeze` is equivalent to `"bar"f`, which will not make a copy
every time `foo` is called. See [https://bugs.ruby-
lang.org/issues/8579](https://bugs.ruby-lang.org/issues/8579) for more
discussion.

~~~
jamesbritt
I see. Thank you.

------
taylorfausak
I'm looking forward to `def` returning a symbol (page 11).

    
    
        private static void def main(args) ...; end

~~~
ngcazz
That slide was a bit confusing for my underslept mind. Is that meant as an
example of calling methods which work over the result of defining main (in
this case static and void)?

~~~
lectrick
If you say "private def methodname(args); end",

the "private" keyword already takes a symbol for a method name to privatize,
so in this case the return of "def methodname(args); end" is ":methodname"
which then gets passed to "private" and everything magically works.

------
diminish
I wish they dedicate 2.2 and 2.3 only to performance improvements of the core
and std lib.

~~~
ksec
Yes, JIT to Native Code, Better GC. We have yet to see any "substantial"
improvement.

------
cmaggard
It's unclear from the intro summary, but I'm assuming from the lack of further
explanation that refinements are just GONE, and not just "no longer
experimental"?

~~~
jameskilton
Nope, by "no longer experimental" they are now officially in the core
language. More information here:
[http://rkh.im/ruby-2.1](http://rkh.im/ruby-2.1)

~~~
cmaggard
Ah, well that's something then. Thanks for the clarification.

------
venus
The most important feature for me is mandatory named args:

    
    
      def foo(bar:)
    

Named args with defaults solved one half of the problem we'd been solving with
the "options hash"; now that's the second half. Can't wait!

------
dgregd
Is it possible to add optional typing to Ruby? Something similar to what Dart
has.

Optional typing would be very useful for big Ruby apps.

~~~
rev_null
I'd be intrigued to see how a ruby type checker would handle boolean
expressions.

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

~~~
thedevelopment
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](https://github.com/deivid-rodriguez/pry-byebug) \- maybe that'll work?

~~~
andyl
Yesss - that worked. Tip of the day - thanks a ton !!

