While pipes are great in Elixir I think it’s important to look at the total cost to adding any new syntax in the context of the language that is considering them.
In the JS ecosystem, idiomatic nested function calls are read from the inside out. And in most cases that is highly readable because a single layer of nesting is all you need.
This proposal flips that on its head, so you have to retrain yourself to read code in a new way based on the presence of a |>. That adds significant cognitive overhead, especially in code that isn’t well written or that is already complex.
Your example looks nice, but also just as nice is the .then() syntax you could have used.
Now we’ll see code bases with both styles. You’ll have some team members who love pipes so much they’ll never call a function the old way doing x |> console.log and the rest of the team doing console.log(x).
This is not elixir pipes. Elixir pipes are sound because they are piping to a function. Piping to a statement is not the same thing and it will become more clear in actual usage just how bad these are. Remember % in js is also modulo, and "test" % "ing" returns NaN. NaN is infectious since basically anything that operates on NaN returns NaN. "test" % "ing" + "ana" returns NaNana . You can quickly see how these pipes (as implemented) are so bad they might as well be language sabotage.
That is concise, readable, and does not have any room at all for error handling. If this was Rust, it could at least be turned into something which returned the right Err for what was happening.
Without something like that, trying to add error handling to the things which may blow up would instantly turn it into gibberish. Every single function here can fail (the HTTP request could fail, the data returned could be unparseable as JSON, or not have the right format). We should be trying to make our languages encourage us to write code which can handle those errors naturally, rather than encouraging us to write fragile code.
But it allows a fully functional style, and so you can do railway oriented programming[0], where every function has a success and failure route. The top level code looks the same as that without error handling.
To me this is both concise and readable: