These are all great but when are we getting optional typing? If the js ecosystem wasn't a clown operation my language of choice would be typescript instead of ruby.
New Features in Ruby 2.4
51–60 of 76 posts
Re: New Features in Ruby 2.4
#52Why 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
Re: New Features in Ruby 2.4
#53Re: New Features in Ruby 2.4
#54Earlier 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.
Example
ruby -ne 'puts $1 if $_ =~ /^(([\d\.])+)/' Re: New Features in Ruby 2.4
#55Ruby 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?
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
#56Ruby 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.
Re: New Features in Ruby 2.4
#57Some 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 ?
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
#58Ruby 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…
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
#59Earlier 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\.])+)/'
Re: New Features in Ruby 2.4
#60Earlier 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…