Any thoughts on Ruby 2.6?

Ben Halpern on December 24, 2018

Ruby 2.6.0-rc2 has been released and the stable should be around the corner.

This is a nice post going over some of the new stuff.

Any thoughts here?

markdown guide
 

Yes to union, the new merge reminds me of Object.assign in JS, not psyched about the breaking change and this feature here seems unnecessary and confusing:

double = proc { |x| x * 2 }
increment = proc { |x| x + 1 }
(double >> increment).call(2) #=> 5
(double << increment).call(2) #=> 6

Did we really need an operator to invert the order of composition of anonymous functions? 🧐

Why not simply invert the functions?

(double >> increment).call(2) #=> 5
(increment >> double).call(2) #=> 6

The thing I find more interesting is not mentioned in the article, the preview JIT compiler. It's not enabled by default but it could speed up long lived processes like web apps. It's described on ruby-lang.org -> Ruby 2.6.0-rc2 Released

 

not psyched about the breaking change

I wonder, how do you plan to upgrade. Literally any gem you use might rely on

case date
when date1..date2 then ...
end

I am not saying it might be hidden behind cases, select(&range.method(:===)) and others inside your own code.

This change is insane.

 

Well, in theory you're supposed to have tests so failing tests should start breaking. But yeah, it's going to take work from some gem authors. The good thing is that the change has been in Ruby trunk for seven months so people might have already started fixing their code.

In their defense, Rubysts were relying on the wrong behavior on a feature badly implemented. See the issue on the bug tracker.

I don't know about the example you made, I don't think I've ever used the case statement :-D

In theory my tests should not test the core functionality of the language I use. I explicitly insist of removing such tests from the test suit during CRs. So no, tests won’t start breaking in the vast majority of the gems.

Also, as a maintainer of several OS gems I can tell that I don’t have time to run tests against each commit into core trunk, otherwise I would not be able to perform my regular duties.

Since triple-equal aka case-equal is one of the most powerful features of the language, very many gems use it to some extent. Luckily enough, not all of them deal with ranges, but I am positive that all the gems I maintain would break if they were to break Proc#=== behavior.

And, the last but not the least, that is not the first time they totally screw the version up. None of my gems worked on 2.3 when they broke __caller__ to return the same value as __method__. This is not exactly what I would expect from the mature enough language. Only Python did worse.

I agree you shouldn't test core functionalities but if something that returns true suddenly returns false some tests will break. If they don't maybe they're not writing the right tests.

I feel like a maintainer of a gem should keep an eye on the changelog of the language the library is written on. At least to check if there are new features that one can take advantage of.

Anyhow, I don't like either but I don't think it's an insane idea. There's no right time to fix a bad behavior people built their libraries on, unfortunately

Within ranges we don’t explicitly test boundaries. We test our internal behaviour for somewhat within the range and somewhat outside of it. Not the boundaries.

a maintainer of a gem should keep an eye on the changelog

In the ideal world she indeed should. Unfortunately, there are many other activities to be performed and I could dedicate some time to update my gems for the new Ruby version only when it’s released. The alternative would be to abandon gems support at all. I still have only 24 hrs/day and I do not even do ruby anymore. I feel like that is the common pattern among a part of ruby community.

There's no right time to fix a bad behavior people built their libraries on

Very true. The thing is you don’t fix it. You say “the implementation of that sucks, but bear with it.” Or you deprecate the behaviour, print boring warnings for at least one major version further and only then you change it. That is how it’s being done in languages made and supported with a care about end-users.

You’ll see how it would go with upgrades to 2.6.

Very true. The thing is you don’t fix it. You say “the implementation of that sucks, but bear with it.” Or you deprecate the behaviour, print boring warnings for at least one major version further and only then you change it.

Yeah, true that, they should have put warning signs everywhere for 2.6 and maybe fixed it in 2.7 (or Ruby 3?).

 

From the linked article, this is classic Ruby:

non-ASCII constant names}

Constant names can now start with non-ASCII capital letters. I am not sure how useful this is, but you can do funny things like:

class Σ♥²; end

😄

 

Range#=== breaking change in the minor version update.

I am so glad I do not use Ruby anymore!

 
code of conduct - report abuse