[theshadow]

It's amazing that considering Ruby's philosphy we didn't have named arguments until now. I think this was a case where the idiom of using hashes as named arguments working well enough that the core team didn't feel the need to address it earlier, still proper keyword arguments are going to be great.

I thought Matz was going to drop refinements for 2.0 for now?

[lobster_johnson]

> the idiom of using hashes as named arguments working well enough that the core team didn't feel the need to address it earlier

Hashes are hideously expensive, though: For every method call, an entire object has to be populated and hashed. The hashing is fast enough for symbol keys, sure, but it's still a whole data structure that must be allocated and later garbage collected.

Since Ruby hashes are mutable and there is no way to track the mutation across methods, the compiler cannot optimize single-use hash literals into a constant. (When all keys and literals are values it could pre-allocate a structure that is copy-on-write internally, but to my knowledge it doesn't do this.) For example, this is a typical pattern:

    def generate_useless_stuff(options = {})
      path = options[:path] || @default_path
      value = options[:value]
      File.open(path, "w") { |f| f << ("*" * value) }
    end

    generate_useless_stuff(value: 42)

In a statically-typed language, the compiler would know that {value: 42} was created once and never reused, and since the value is a literal, the :value key could simply have been plugged directly into the value variable. Also, the lookup of :path is completely unnecessary in this case.

Often all the options are optional, and even then a call to generate_useless_stuff() will generate an empty hash. This is why I tend to write methods, when performance-sensitive, as:

    def generate_useless_stuff(options = nil)
      path = options[:path] || @default_path if options
      value = options[:value] if options
      File.open(path, "w") { |f| f << ("*" * value) }
    end

Of course, this decreases allocation while adding complexity.

So yes, I absolutely agree that it's amazing. :-) I think the core team should have considered it earlier.

[VeejayRampay]

Some might argue that if you're using Ruby and are worried about the cost of hashes, you might want to consider switching to another language. There are other concerns about "expensiveness" in Ruby that far outweigh usage of hashes.

[lobster_johnson]

That seems like a false dichotomy to me. Clearly I can worry about the cost of hashes and be using Ruby productively and performantly. (Unless I were writing programs whose performance was really dependent on hash performance; I don't use Ruby in those cases.)

Anyway, everything adds up. Even for webapps in Rails or Sinatra, the sheer number of method calls in a single template may contribute significant overhead to the rendering of a page. Which means that shaving a few microseconds off a method call may in fact boost performance measurably. I am hoping this will be the case with named arguments.

[reinhardt]

As a Python dev keyword arguments are among my top language features. Kinda surprised that Ruby doesn't have them yet.

On a slightly off-topic note, what's the best way to dive into Ruby coming from (strong) Python background? I bet the syntax wouldn't take more than a weekend to get used to but I'm more interested in the less trivial stuff (semantics, idiomatic style, dev environment, 3rd party lib ecosystem etc.)

[milep]

For the dev environment you can use rbenv or rvm and your favorite text editor. https://www.ruby-toolbox.com/ is a good source for 3rd party libs. About idiomatic style I have learned from reading code from some popular gems.

[bratsche]

I think he just dropped certain parts of refinements, because they could potentially cause pretty major performance problems.