Ruby 2.0.0-preview2 released

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/50443

by charliesome • 14 years ago

84 28 14 years ago

blade.nagaokaut.ac.jp

delano2• 14 years ago

Dtrace is such an awesome technology and the support in Ruby 2.0 is going to help improve a lot of projects.

MikeKusold• 14 years ago

"DTrace can be used to get a global overview of a running system, such as the amount of memory, CPU time, filesystem and network resources used by the active processes. It can also provide much more fine-grained information, such as a log of the arguments with which a specific function is being called, or a list of the processes accessing a specific file."

For anyone else that wasn't aware what Dtrace does.

Wikipedia Link: http://en.wikipedia.org/wiki/DTrace

delano2• 14 years ago

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

VeejayRampay3• 14 years ago

I think that is the biggie really, DTrace probes. Much more than refinements or keyword arguments, GC or other features.

Put in the right hands, this will prove to be a deadly weapon.

mitchty• 14 years ago

Anyone else getting compile errors with the latest clang on mountain lion?

num2int.c:82:21: error: expected ')'

    sprintf(buf, "%"PRI_LL_PREFIX"d", NUM2LL(num));

                    ^

ajasmin• 14 years ago

Is that even valid C code?

emillon• 14 years ago

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

rwmj• 14 years ago

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

danielpal• 14 years ago

This is fantastic.

The thing I like the most about ruby is how much thought is put into code readability and programming experience.

My favorite features of this release:

1. Keyword arguments: I can stress how important this is for code readability and also prevents some bugs.

2. Refinements: This is going to make code easier to maintain and more "custom". I can't wait to add a few things we constantly use on String etc.

tomstuart• 14 years ago

Refinements aren’t all good news: http://blog.headius.com/2012/11/refining-ruby.html

halostatue• 14 years ago

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.

theshadow• 14 years ago

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?

bratsche• 14 years ago

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

lobster_johnson2• 14 years ago

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

reinhardt• 14 years ago

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

VeejayRampay3• 14 years ago

Keyword arguments are not that important. They're a very nice feature but most of the benefits it will bring could be emulated easily using hashes (not telling you anything you didn't already know I guess).

It's nice to see that we won't have to rely on smart hacks though and that real keyword arguments are now available, but it's nowhere near earth-shattering.

As for refinements, it's theoretically a very nice feature, but it seems that the details are still hazy and the green-ness of the feature raises more eyebrows than it solves problems.

w1ntermute• 14 years ago

OT: does anyone else notice that the Japanese text doesn't render correctly (in Chrome and Firefox on Linux & Windows) unless they manually change the encoding to EUC-JP? Why doesn't it work with Unicode, for the Ruby ML, of all things?

cmwelsh• 14 years ago

The server does not send the charset in the response headers, and the document that is generated does not contain a charset like this:

    <meta charset="utf-8">

Either of those two options should fix the page, but I assume Japanese browsers have different default charset than ours since no one has fixed it yet.

subwindow• 14 years ago

Just a reminder that the spec for refinements continues to change radically: http://bugs.ruby-lang.org/issues/4085

As far as I understand it the current spec is to have "using" be available only to main and only apply in the file scope. IMHO this makes the feature nearly useless.

aneth4• 14 years ago

If you explore the topic, there are solid reasons from performance, to vm ports, to readability for why refinements have been curtailed. I'm quite happy with this. The original refinement support would have held ruby back, even if it had its uses.

Rapidwire• 14 years ago

^^ What an apologist...

sams99• 14 years ago

Does anyone know what ever happened with Kiji, it seems a generational GC for Ruby has already been coded twice, yet in 2.0 it seems the only big change is the CoW friendly GC

mitchellh• 14 years ago

I don't know the specific characteristics of Kiji, but I know that it is not a real generational GC. A generational GC that doesn't break every C extension is impossible because Ruby passes around direct pointers, so Ruby objects can't be moved in memory.

That being said, I'm not a language or VM guy, so take what I say with a grain of salt.

lhnn• 14 years ago

Calling it: There will be a blog post titled "Ruby Two's Day" on release.

Ruby 2.0.0-preview2 released

Related Stories