Ruby 2.0.0 feature freeze | Hacker News Reader

Ruby 2.0.0 feature freeze

blade.nagaokaut.ac.jp

213 pointsujeezy33 comments

Open articleView on HN

So, anyone has a list of the major changes coming in 2.0?

Btw, slightly misleading title. It kind if implies that 2.0.0 is out.

According to Matz last year,

"The version number goes up to 2.0 but the changes are rather small. Smaller than the ones we made in 1.9."

http://www.rubyinside.com/ruby-2-0-implementation-work-begin...

Here's a Quora thread with links to a presentation by Matz and a summary by Yehuda Katz: http://www.quora.com/Ruby-programming-language/What-are-the-...

"Language improvements:

- Named arguments.. 1.step(by: 2, to: 10) { ... }

- Selector namespaces (unclear to me whether this differs from refinements as described by Katz)

- Multiple inheritance

Interpreter Improvements:

- Incremental performance improvements over 1.9's VM

- Better compatibility with non-unix environments and small/constrained devices (embeddable)

- Sandboxed VM's (VM per thread)"

Matz's presentation: http://www.youtube.com/watch?feature=player_embedded&v=t...

Yehuda's summary of "refinements": http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-pra...

> * Sandboxed VM's (VM per thread)

This will not make it into Ruby 2.0.0:

https://bugs.ruby-lang.org/issues/7003

Multiple inheritance is the major one for me.. been waiting a long time for this

What does multiple inheritance provide that isn't better achieved through composition/modules?

Why is that even something worth working on? I find modules work pretty good.

Agree with you. Didn't we learn from C++ that multiple inheritance is good in theory but in practice a horrible idea? Ruby already lets you be 'magical' in too many ways.

It is also available in Eiffel, OCaml and Python.

So there are some good ways to make use of it.

But I agree interfaces/traits is a better way of dealing with multiple inheritance scenario.

Perl (5 & 6) also has multiple inheritance. Current best practise in the Perl community is to avoid using MI and instead make use of roles.

ref: https://metacpan.org/module/Moose::Role | http://en.wikipedia.org/wiki/Perl_6#Roles | http://modernperlbooks.com/mt/2009/05/perl-roles-versus-inhe...

> Didn't we learn from C++ that multiple inheritance is good in theory but in practice a horrible idea?

No, we learned from C++ that C++ multiple inheritance is an atrocity. Python's MI works in a clear and obvious way, similar[0] to how the Ruby inheritance chain is clear and obvious. MI really doesn't fit Ruby though, and IMHO would look too bolted on.

Most of the time the problem is people beating the platform they develop on into submission, instead of embracing it by getting a clear picture of what happens.

[0] As _why said[1], python and ruby are damn close: you can easily get something similar to Ruby's modules and inject them dynamically in the inheritance chain: https://gist.github.com/3951273

[1] https://github.com/whymirror/unholy

Magic is bad, but multiple inheritance isn't magic; it's clear and obvious, the only potential wrinkle being method resolution order when two superclasses define the same method, which is fine as long as it's consistent and documented.

Almost all of the problems with multiple inheritance in C++ are to do with the static type of an instance, and go away in a language where everything is virtual by default, as in ruby.

Sometimes you want to express multiple is-a relationships at the same time. In that case, composition is a hack, and multiple inheritance is a better match for the concept.

I prefer having more options how my objects behave than fewer.

But, since Ruby 2.0 does not and will not have multiple inheritance, this is all off-topic.

I'm seeing contradictory information about this. Is multiple inheritance in or out?

> Named arguments

yes, though it's basically an optional argument hash. AFAIK, you can't do required named arguments without weird hacks, or specifically checking the arguments. For example:

    irb(main):007:0> def foo(bar: bar, baz: Object.new); [bar, baz]; end
    => nil
    irb(main):008:0> foo(bar: 1)
    => [1, #<Object:0x007fcaa40db4e0>]
    irb(main):009:0> foo(baz: 1)
    NameError: undefined local variable or method `bar' for main:Object
    	from (irb):7:in `foo'
    	from (irb):9
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):010:0>

This hack makes the "bar" parameter required, but only because the value is evaluated when the method is called, and you get a NameError (rather than an ArgumentError).

> Selector namepaces

yes, but it's called refinements. You can see how they're used here: https://github.com/ruby/ruby/blob/trunk/test/ruby/test_refin... (sorry for the link to a test, I'm feeling lazy ;-) )

> Multiple inheritance

Sorry, there won't be multiple inheritance.

> Incremental performance improvements over 1.9's VM

yes, ko1 has been working on removing / optimizing bytecodes in the VM.

> Better compatibility with non-unix environments and small/constrained devices (embeddable)

I don't know of any work on this other than mruby, which isn't MRI.

> Sandboxed VM's (VM per thread)

nope. https://bugs.ruby-lang.org/issues/7003

Other stuff:

* DTrace probes

* Better within ruby tracing https://bugs.ruby-lang.org/issues/6895

I run edge ruby against rails daily. The main incompatibilities I've hit in Ruby 2.0 are what methods respond_to? searches (I've blogged about that here: http://tenderlovemaking.com/2012/09/07/protected-methods-and... ), and the `Config` constant has been removed (which is sometimes an issue for C extensions).

EDIT

Just thought of this for the required args:

    irb(main):001:0> def foo(bar: (raise ArgumentError), foo: Object.new); [bar, foo]; end
    => nil
    irb(main):002:0> foo(bar: 1)
    => [1, #<Object:0x007fc65a882f48>]
    irb(main):003:0> foo(foo: 1)
    ArgumentError: ArgumentError
    	from (irb):1:in `foo'
    	from (irb):3
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):004:0>

You could probably define a private method like `required` or some such, like this:

    irb(main):001:0> def required(name); raise ArgumentError, "missing param: %s" % name; end
    => nil
    irb(main):002:0> def foo(bar: required(:bar), foo: Object.new); [bar, foo]; end
    => nil
    irb(main):003:0> foo(bar: 1)
    => [1, #<Object:0x007fcfea143338>]
    irb(main):004:0> foo(foo: 1)
    ArgumentError: missing param: bar
    	from (irb):1:in `required'
    	from (irb):2:in `foo'
    	from (irb):4
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):005:0>

> > Multiple inheritance

> Sorry, there won't be multiple inheritance.

Thank all that is holy in the world.

Amen to that.

C++ pretty much ruined that party for everyone.

another nice vm improvement would be the introduction of unboxed floats in 64 bit architectures (akin to Fixnums)

https://github.com/ruby/ruby/commit/b3b5e626ad69bf22be3228f8...

So it's syntactic sugar? What a shame. The whole point is having the language handle it so its default behavior is well-known and uniform and not implement umpteenth patterns and validations[0].

[0] e.g assert_valid_keys (raising ArgumentError on a mismatch so it's really only for options={} pattern: http://api.rubyonrails.org/classes/Hash.html#method-i-assert...

Well, it does actually define locals. But, IIRC, it uses the symbol hash parsing productions, so the default values are required. The only way to specify required parameters (without the above hacks) is to do a traditional method definition:

    irb(main):001:0> def foo(bar, baz: Object.new); [bar, baz]; end
    => nil
    irb(main):002:0> foo(1)
    => [1, #<Object:0x007fbc39161ed8>]
    irb(main):003:0> foo(1, baz: 10)
    => [1, 10]
    irb(main):004:0> foo(baz: 10)
    ArgumentError: wrong number of arguments (0 for 1)
    	from (irb):1:in `foo'
    	from (irb):4
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):005:0>

I really like the required(name) solution.

  module RequiredParameter
    refine Kernel
      def required(name)
        raise ArgumentError, ...
      end
      private :required
    end
  end

Can't wait to test this code. :P

I believe this also includes the bitmap marking GC changes which will make the GC copy-on-write friendly. This is pretty important for a lot of folks running Ruby web servers.

See, for example:

http://patshaughnessy.net/2012/3/23/why-you-should-be-excite...

This is probably the most exciting part to me: Having copy-on-write without having to run REE.

You can have this right now. We back ported the GC. Shopify in running on this ruby version in production.

https://gist.github.com/1688857

Thats great! Hope this will work on 1.9.3p286 as well?

Yes, the Falcon patches work like a charm against p286.

https://bugs.ruby-lang.org/projects/ruby-trunk/roadmap#2.0.0

rename title, 2.0.0 is still months away. This is just a requested feature freeze.

How is "Ruby 2.0.0 feature freeze" an inaccurate title?

I ask because it has been common to use that terminology with Python releases for as long as I can remember, as well as with other projects I've worked on or am familiar with. We would have said the CPython 3.3.0 feature freeze was in June, with the final release happening last month.

The title at the time of jfaucett's comment was just "Ruby 2.0.0".

Oh, would love to have had .present? added to ruby 2.0

Any performance and memory usage improvement benchmarks? I was hoping Ruby 2.0 will no longer be dog slow...

Will the GIL still be present in 2.0?

It'll be there.

Reply on news.ycombinator.com