Hacker News Reader

Comment by davidroetzel | Hacker News Reader

While I do not disagree with any of the proposed features, I am not sure, what they would accomplish. Could someone point out, what kind of applications would benefit from those changes?

Is this just about making ruby more like node (substituting callbacks for promises)?

Also, do all of these features really need to be implemented on the interpreter level?

View on HN

It is, at least, about making Ruby more concurrent. Rubinius eliminates the global interpreter lock, which helps, but Ruby's execution model is still very much thread-oriented; Ruby's fibers are very slow, and are not good enough for Node-style concurrency.

It is also about wiping the slate clean. Ruby still has some ugly stuff inherited from Perl (globals for regex results, or the use of unreadable "magical" globals such as $:). There are many areas where years of experience can help us design a better language.

To me, that is more like Ruby 3.0, or a similar languages with another name.

How will this turn out? Matz will approve it? If yes why not make Rubinius the default implementation?

If not, then ?

>Ruby still has some ugly stuff inherited from Perl (globals for regex results, or the use of unreadable "magical" globals such as $:)

And Ruby also has some pretty stuff inherited from Perl like postfix statements & first class regex so it wouldn't be good to strip out all of Perl's influences! Gosh even Ruby's blocks are (partly) inspired by Perl's list block functions...

  array.map {|n| n * 2}

  map {$_ * 2} @array;

However I do agree that Ruby's magical global variables should be removed because they're not dynamically scoped like in Perl.

NB. It should be noted that not all Ruby magical variables even come from Perl. For eg. $: doesn't and thankfully Perls $= does something quite different to Rubys! - https://news.ycombinator.com/item?id=5072925

Reply on news.ycombinator.com