Ruby 2.0.0-preview2 released

^^ What an apologist...

I am hoping for an update on that from Charles, because that article was written based on the the previous version of the spec.

I think that the latest refinement spec addresses at least some of the issues he raised.

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

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

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

And the overhead is extremely minimal which allows you to collect data in production while an application is running (without restarting).

Yes, if PRI_LL_PREFIX expands to a string literal, the literals get merged together.

Not as written, but it's possible that PRI_LL_PREFIX is some sort of macro expanding to a string (similar to PRIi64 which is standard C).