Live data from Hacker News

New Features in Ruby 2.4

blog.blockscore.com

51–60 of 76 posts

Re: New Features in Ruby 2.4

#52
post #47

Why do the old match operators now implicitly set a global variable? I feel like in a year I'm going to be debugging some really weird race conditions because of that change and I can't see any value in it...if I want to use the value of a match operator I'll _always_ save it to a local variable. Can anyone shed any light on this, because my first attempts at grok'ing this change have me really blown away.

They have been setting the global variable before. This is not a new behaviour. I think it was to match Perls behaviour iirc

Ahh, thanks for the clarification I had no idea this was old behavior but it looks like the new method might allow them to deprecate what I would consider an anti-feature later.

Re: New Features in Ruby 2.4

#54
post #52

Earlier quoted context omitted.

They have been setting the global variable before. This is not a new behaviour. I think it was to match Perls behaviour iirc

Ahh, thanks for the clarification I had no idea this was old behavior but it looks like the new method might allow them to deprecate what I would consider an anti-feature later.

This is the kind of stuff that is great for shell scripting / one liners. I doubt they are ever going deprecate it. Maybe the best thing is to rewind your mind 30 minutes and pretend you never read about it : )

Example

    ruby -ne 'puts $1 if $_ =~ /^(([\d\.])+)/' 

Re: New Features in Ruby 2.4

#55
post #27

Ruby is the first language I really like. The core concept of the language is small, just not easy to get, but the change on how to programming is significant. Sadly, Ruby is not the language for the multi-core world, and many advantages of using it is disappearing. Although Ruby is changing, 2.3, 2.4, maybe 3.0, but what's the difference?

First of all, Ruby has a very ambitious goal for version 3.0, which most likely involves some kind of thread parallelisation.

Second, I would not say Ruby is not a language for the multi-core world. There are tens of thousands Ruby production environments over the world that make excellent use of multi-core machines. They run Ruby on problems that are embarassingly parallel such as web applications using process managing application servers such as Phusion Passenger or Unicorn. This is the way many modern web application platforms parallelize, including Node.JS and Python.

Third lack of paralellization is not a language feature. Both JRuby and Rubininus support threads without a GIL. Projects like Celluloid and Concurrent-Ruby make use of this.

Re: New Features in Ruby 2.4

#56
post #42
post #27

Ruby is the first language I really like. The core concept of the language is small, just not easy to get, but the change on how to programming is significant. Sadly, Ruby is not the language for the multi-core world, and many advantages of using it is disappearing. Although Ruby is changing, 2.3, 2.4, maybe 3.0, but what's the difference?

You should check out Elixir. It is heavily inspired by the Ruby language yet makes concurrency easier than many other languages.

yeah, Elixir is a good option, indeed.

Re: New Features in Ruby 2.4

#57
post #2

Some of these are pretty amazing, like the `digits` method and the new OptionParser functionality (which seems to be a sort of standard library equivalent to doctopt!). That being said, I can't help but shake my head at the section about "multiple assignment of conditionals: "You can now assign multiple variables within a conditional...You probably shouldn’t do that though." Am I alone and thinking that it's a little…

I like the feature, but just for understanding, will the assignment always be truthy if any of the assigned variables are set? The example is branch1 = if (foo, bar = %w[foo bar]) 'truthy' else 'falsey' end branch2 = if (foo, bar = nil) 'truthy' else 'falsey' end branch1 # => "truthy" branch2 # => "falsey" What about branch3 = if (foo, bar = ['foo', nil]) 'truthy' else 'falsey' end ?

Haven't tried it, but the assignment semantics is that the return of the assignment expression is always the right hand side of the operator. They probably kept that semantic. So

  foo, bar = ['foo', nil]
evaluates to

   ['foo', nil]
which is truthy.

If the code was:

  if (foo, bar = [nil, nil])
    'truthy'
  else
    'falsey'
  end
It'd still be truthy even if no variables were "set" (they were actually set, explicitly to nil, but you get the idea) because [nil, nil] is truthy. It doesn't have anything to do with the values of the variables after the assignment, just what's on the right hand side.

Re: New Features in Ruby 2.4

#58
post #55
post #27

Ruby is the first language I really like. The core concept of the language is small, just not easy to get, but the change on how to programming is significant. Sadly, Ruby is not the language for the multi-core world, and many advantages of using it is disappearing. Although Ruby is changing, 2.3, 2.4, maybe 3.0, but what's the difference?

First of all, Ruby has a very ambitious goal for version 3.0, which most likely involves some kind of thread parallelisation. Second, I would not say Ruby is not a language for the multi-core world. There are tens of thousands Ruby production environments over the world that make excellent use of multi-core machines. They run Ruby on problems that are embarassingly parallel such as web applications using process mana…

1. Ruby will support parallelization, it’s just a matter of time.

2.Passenger and Unicorn are multi-process, which due to developers can make use of nearly nothing in Ruby, and that's why gems like https://github.com/grosser/parallel come out.

3. The language implementation detail matters a lot. Too many gems are not thread-safe. JRuby is an option, but not that good, as there're too many other options under JVM platform. Rubininus is awesome, I wish it comes out earlier.

Re: New Features in Ruby 2.4

#59
post #52

Earlier quoted context omitted.

Ahh, thanks for the clarification I had no idea this was old behavior but it looks like the new method might allow them to deprecate what I would consider an anti-feature later.

This is the kind of stuff that is great for shell scripting / one liners. I doubt they are ever going deprecate it. Maybe the best thing is to rewind your mind 30 minutes and pretend you never read about it : ) Example ruby -ne 'puts $1 if $_ =~ /^(([\d\.])+)/'

I knew things would make sense the more I learned about it. Thanks, TIL. Now I'll pretend I never knew about this so I'm never tempted to abuse it.

Re: New Features in Ruby 2.4

#60
post #57

Earlier quoted context omitted.

I like the feature, but just for understanding, will the assignment always be truthy if any of the assigned variables are set? The example is branch1 = if (foo, bar = %w[foo bar]) 'truthy' else 'falsey' end branch2 = if (foo, bar = nil) 'truthy' else 'falsey' end branch1 # => "truthy" branch2 # => "falsey" What about branch3 = if (foo, bar = ['foo', nil]) 'truthy' else 'falsey' end ?

Haven't tried it, but the assignment semantics is that the return of the assignment expression is always the right hand side of the operator. They probably kept that semantic. So foo, bar = ['foo', nil] evaluates to ['foo', nil] which is truthy. If the code was: if (foo, bar = [nil, nil]) 'truthy' else 'falsey' end It'd still be truthy even if no variables were "set" (they were actually set, explicitly to nil, but yo…

Interesting. In particular the result with both values being nil is something I would find pretty counter-intuitive.
Post reply on HN