[maz1b]

It's never Christmas without a new ruby version.

The ruby::box thing looks pretty interesting, from a cursory glance you can run two simultaneous versions of something like a feature or rollout much more conveniently.

Also being able to do

  if condition1
     && condition2
    ...
  end

on multiple lines rather than one - this is pretty nifty too!

[WJW]

I'm kinda hoping that eventually each ractor will run in it's own ruby::box and that each box will get garbage collected individually, so that you could have separate GCs per ractor, BEAM-style. That would allow them to truly run in parallel. One benefit should be to cut down p99 latency, since much fewer requests would be interrupted by garbage collection.

I'm not actually in need of this feature at the moment, but it would be cool and I think it fits very well with the idea of ractors as being completely separated from each other. The downside is of course that sharing objects between ractors would get slower as you'd need to copy the objects instead of just sharing the pointer, but I bet that for most applications that would be negligible. We could even make it so that on ractor creation you have to pass in a box for it to live in, with the default being either a new box or the box of the parent ractor.

[byroot]

They already truly run in parallel in Ruby 4.0. The overwhelming majority of contention points have been removed in the last yet.

Ruby::Box wouldn't help reducing contention further, they actually make it worse because with Ruby::Box classes and modules and an extra indirection to go though.

The one remaining contention point is indeed garbage collection. There is a plan for Ractor local GC, but it wasn''t sufficiently ready for Ruby 4.0.

[tebbers]

I've been doing

  if condition1 && 
       condition2
       ...
  end

for ages and it seems to work find, what am I missing with this new syntax?!

[AlecSchueler]

I prefer the new way because if you want to remove one condition you just delete the line rather than having to edit in multiple places.

[Sammi]

Less likely to cause git merge conflict as you don't change the original line. You only add one.

[fuzzythinker]

In languages where placement don't matter, like c/js, I prefer leading booleans. It makes it much easier to see the logic, especially with layers of booleans.

[mantas]

Personally && in the new line seems to be much better readability. Can’t wait to use some smart cop to convert all existing multiline ifs in my codebase.

[mathgeek]

For folks who scan code bases based on the front of lines, it makes it easier to grok. Also helps with deleting and inserting lines (similar to leading or trailing commas in lists).

[zelphirkalt]

It's funny how I have been doing this way of writing the conditions in languages, where one can, like Python (if you use a pair of parentheses) and linters have yelled at me for ages to put the binary operator on the previous line. People herald these quite subjective things like truths, just because there is some tool, that they can delegate responsibility to.