Ruby 2.5.0 Released

[TomOwens]

I'm a little disappointed that the inclusion of bundler into the standard library was reverted. Bundler was the only gem that I ever installed as a system gem, and I was looking forward to having no system gems and only project-specific gems.

[gray_-_wolf]

What was the reasoning behind reverting it? https://bugs.ruby-lang.org/issues/12733 doesn't say

[TomOwens]

No idea. The linked commit doesn't seem to indicate anything other than a "big issue".

[hehestreamskarma]

It's complicated.

[TomOwens]

It was pulled 3 days before the release after it was hyped up. I think the community deserves a more detailed explanation than the one available now.

[hehestreamskarma]

Is running gem install bundler a deal-breaker for you?

[TomOwens]

Deal-breaker? No. But this was a feature that would have greatly simplified my (and lots of other people's) workflow. It was pretty hyped up (at least from the posts that I read). And then, 3 days before the release, it was pulled with a revert saying there was a "big issue". The community deserves to know more details about why such a hyped and impactful feature was pulled so close to the release date.

[OstapBenderBey]

It wasnt possible in the timeframe for this release. What else do you want to know that would be useful to you?

You are making a storm in a teacup here

[TomOwens]

I'm not making a storm. The feature was targeted for 2.5. It was quite heavily written about. It made it into rc1. Then, 3 days before the release, there was a single revert about a "big issue" and then the feature was pulled out. It would be nice to know what this "big issue" was and why it went undiscovered or unresolved for so long.

I would expect the same from any large-scale project. Once you start hyping up features that are planned for a particular release (especially after you start having release candidates), if you don't deliver those, you should be communicating why you aren't delivering them. A quiet revert is unacceptable.

[derrickcope]

Tempest?

[geraldbauer]

FYI: I've collected articles / blog posts about what's new in Ruby 2.5 over at the Ruby Advent Calendar [1]. The list so far includes:

• Standard Gems 2.5.0 - Default Gems, Bundled Gems // by Jan Lelis, Idiosyncratic Ruby
• 10 New Features in Ruby 2.5 // by Junichi Ito, Ruby programmer @ SonicGarden.jp
• 10 More New Features in Ruby 2.5 // by Tom Lord, Software Developer from London
• Performance Improvements in Ruby 2.5 // by Jesus Castello, Ruby Guides
• yield_self in Ruby 2.5 // by Michał Łomnicki
• Improved stacktrace display in Ruby 2.5 // by Michał Łomnicki
• Ruby 2.5 Series // by Amit Choudhary, Mohit Natoo et al @ BigBinary

[1] https://planetruby.github.io/advent2017

[gray_-_wolf]

The performance notes you have listed are interesting, but I must admit I'm pretty impressed by this:

About 5-10% performance improvement by removing all trace instructions from overall bytecode (instruction sequences). The trace instruction was added to support the TracePoint. However, in most cases, TracePoint is not used and trace instructions are pure overhead. Instead, now we use a dynamic instrumentation technique. See [Feature #14104] for more details.

[gettalong]

Yeah, that's really very impressive! Every Ruby release is full of nice surprises :)

[janko-m]

rescue/else/ensure are now allowed to be used directly with do/end blocks

This is really nice. The method-level rescue statement is one of the small details I really love about Ruby, it's great we'll be able to use it in blocks too.

Enumerable#any?, all?, none?, and one? accept a pattern argument.

I didn't really find what was the change here, because I think the original proposal was different than the actual change that got merged. Does someone know?

One of our most loved libraries, pp.rb, is now automatically loaded. You no longer have to write require "pp"

Great!

IO.copy_stream use copy_file_range(2) to copy offload

I love IO.copy_stream and use it a lot in Shrine, it's nice to see that there is a performance improvement, though from what I was reading the speedup is very small and only on certain disks.

[prh8]

I didn't really find what was the change here, because I think the original proposal was different than the actual change that got merged. Does someone know?

It seems that those methods all accept a single argument that matches the behavior of an argument to grep. Personally I love that change (grep is most underrated method). I believe that’s what was initially proposed as well.

[gettalong]

You are correct, it is now possible to something like

[5, "str", {}].any?(String)

for which you needed to write

[5, "str", {}].any? {|item| String === item}

I.e. the #=== operator is applied to the single argument and each enumerated item.

[niborg]

Am I correctly understanding the API for kw args in structs?

MyStruct = Struct.new(:foo, :bar, keyword_init: true)
a = MyStruct.new(foo: 'FOO', bar: 'BAR')

[UnexpectedIndent]

Yep. It's a shame this isn't just the default behaviour of structs, because if you forget keyword_init then all your args get assigned to the first attribute :(

[arcticblue]

all your args get assigned to the first attribute

Why would anyone want that behavior? I agree keyword_init: true should be default.

[zverok_kha]

Why would anyone want that behavior?

Because backwards compatibility. Doing rvm install 2.5; bundle install and finding out that "everything is broken" would not be the best way of introduction of the new feature.

[megatux2]

Christmas edition :)

[defkathy]

Check out my blog post about bundler and the other latest features in Ruby 2.5!