11 ms·

Ruby 2.0.0-preview2 released

84 points by charliesome 14y ago

delano 14y ago
Dtrace is such an awesome technology and the support in Ruby 2.0 is going to help improve a lot of projects.
- MikeKusold 14y 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 http://en.wikipedia.org/wiki/DTrace
  - delano 14y ago
    And the overhead is extremely minimal which allows you to collect data in production while an application is running (without restarting).
- VeejayRampay 14y 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 14y 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 14y ago
  Is that even valid C code?
  - emillon 14y ago
    Yes, if PRI_LL_PREFIX expands to a string literal, the literals get merged together.
    - cremno 14y ago
      Ruby supports this too but it will be removed in the future (3.0). The preview doesn't show a warning but 2.0 will. Source: https://bugs.ruby-lang.org/issues/6265 https://bugs.ruby-lang.org/issues/6265 Btw, PRI_LL_PREFIX is defined in Ruby's config.h.
  - rwmj 14y 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).
deleted 14y ago
[deleted]
danielpal 14y 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 14y ago
  Refinements aren’t all good news: http://blog.headius.com/2012/11/refining-ruby.html http://blog.headius.com/2012/11/refining-ruby.html
  - halostatue 14y 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 14y 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 14y ago
    I think he just dropped certain parts of refinements, because they could potentially cause pretty major performance problems.
  - lobster_johnson 14y 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.
w1ntermute 14y 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 14y 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 14y ago
Just a reminder that the spec for refinements continues to change radically: http://bugs.ruby-lang.org/issues/4085 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 14y 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 14y ago
    ^^ What an apologist...
sams99 14y 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 14y 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 14y ago
Calling it: There will be a blog post titled "Ruby Two's Day" on release.

84 points by charliesome 14y ago

delano 14y ago

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

MikeKusold 14y 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 http://en.wikipedia.org/wiki/DTrace
- delano 14y ago
  And the overhead is extremely minimal which allows you to collect data in production while an application is running (without restarting).
VeejayRampay 14y 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 14y 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 14y ago
Is that even valid C code?
- emillon 14y ago
  Yes, if PRI_LL_PREFIX expands to a string literal, the literals get merged together.
  - cremno 14y ago
    Ruby supports this too but it will be removed in the future (3.0). The preview doesn't show a warning but 2.0 will. Source: https://bugs.ruby-lang.org/issues/6265 https://bugs.ruby-lang.org/issues/6265 Btw, PRI_LL_PREFIX is defined in Ruby's config.h.
- rwmj 14y 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).

deleted 14y ago

[deleted]

danielpal 14y 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 14y ago
Refinements aren’t all good news: http://blog.headius.com/2012/11/refining-ruby.html http://blog.headius.com/2012/11/refining-ruby.html
- halostatue 14y 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 14y 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 14y ago
  I think he just dropped certain parts of refinements, because they could potentially cause pretty major performance problems.
- lobster_johnson 14y 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.

w1ntermute 14y 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 14y 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 14y ago

Just a reminder that the spec for refinements continues to change radically: http://bugs.ruby-lang.org/issues/4085 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 14y 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 14y ago
  ^^ What an apologist...

sams99 14y 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 14y 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 14y ago

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