Your comparison is not quite optimised as you use () which is not necessary. But I understand the comparison you make.

But, you can write an optimised pipe in ruby too. I actually did that, because I could not want to be bothered to be restricted via ruby's syntax for pipe-like operations.

Even aside from that, the original claim was about pipes versus method chaining. To me these are not orthogonal to one another; they are very similar. Just with the pipe focusing on tying together different programs and focusing on input-output functionality. Method chaining in ruby is a bit more flexible, we have blocks, and usually the methods chained occur in one class/object or the toplevel namespace (less frequently though, usually). Even the pipe comparison is not ideal, because traditional UNIX pipes don't support e. g. data manipulation via an object-oriented focus. And I want that (see avisynth, but extend the idea there via a) nicer syntax and b) data manipulation for EVERYTHING).

I don't see pipe as being exclusive over method chaining or reverse.

One interesting idea was to add |> elixir's pipe-like operator to ruby. I like that, but indeed, the net-gain in ruby is quite minimal since method-chaining + blocks already offer a ton of flexibility, so I am not sure how |> would fit into ruby 1:1. Still I like the idea, but anyone proposing |> needs to come up with really convincing ideas to matz here. Because people WILL ask what the real difference is to method chaining. Even fail-safe method chaining in ruby though I absolutely hate the syntax via ? there ... it reads like garbage to me. Example:

https://github.com/ruby/ruby/blob/trunk/test/ruby/test_threa...

    t1&.kill&.join

(It has moved since then, so the above link no longer works, been some years since I first saw it. Upon seeing it my brain instantly cancelled any use of "&.", even though I understand the rationale. It is just ugly to no ends. I still like the |> syntax in Elixir though, even though I can not really see what this should do in ruby.)