[Fire-Dragon-DoL]

I wrote something like this in the past, it doesn't make sense in ruby.

The closest ruby way is:

    result = DoStuff
    return something if result.nil? # error, early exit

    result = OtherStuff(result)
    return something if result.nil? # error, early exit

No additional complexity. Otherwise usually it ends up just rewriting "programming".

With pattern matching there are also some alternatives now.

[ismaelct]

What do you think of Ruby's built-in function composition? https://ruby-doc.org/3.2.2/Proc.html#method-i-3E-3E

[Fire-Dragon-DoL]

Interesting, never used it. Usually I have methods but not proc, by the time I have to write `.method(something)` a bunch of times I'd it doesn't make much sense anymore.

I love curried functions by default, but if it's not the default, it never works out even in functional languages like Elixir. You need to have every developer (and new hired developer) pretty much on board with that and exclude every library that doesn't do this, or wrap it (huge burden).

Given those, I'd rather stick to what I wrote. Not my favorite, I loved my brief experience with Elm

[ismaelct]

I understand the sentiment but I think it's highly dependent on context. Where you work at, who you work with, org size, what the problem is, the cost and benefits of each abstraction, etc etc. I think it's our job as developers to put all those things on the scales when deciding what abstractions to use or not use. Whether a pattern is "the default" or familiar is certainly a big factor, but not the only one.