There is pros/cons to both approaches. The Pipe operator in F# works in conjunction with the HM type inference in the language and static functions often assisting the type checker. i.e. features that work together in a language vs tacked on. F# idiomatic code avoids a lot of virtual dispatch seen in Java/C#, etc as compile time polymorphism is typically how re-use occurs vs objects. I find F# favors compile time abstractions a little more than Scala historically although I note that could be changing.
For most of these proposals it is just syntactic sugar around invoking the function with a placeholder. The pipe in F# is slightly different in that most of the time it has no intermediate lambdas and is compiled in a more performant form. The downside is that unless you allocate that lambda yourself it has to be the last arg. On the plus side like most things in F# it is concise but shows all behavior explicitly - its usually a warning sign if you have to do that and helps reason about performance. Sometimes its a sign that the original function isn't written right or some other inline wrapper could be used for other usages of the function. You can inline a template to rearrange the arg's (inline) to avoid the lambda allocation as well.
This allows some level of re-use and performance benefits avoiding virtual table dispatch and a lambda allocation for many common methods (e.g. map, fold, iter, etc)
The pipe in F# is slightly different in that most of the time it has no intermediate lambdas and is compiled in a more performant form
I believe the point made in the discussion is that the F# proposal leads to intermediate lambda if the function does not have the right arity. JS also don't do HM so that point is moot.
The people supporting the Hack proposal made the point that their expressions do not desugar to lambda and has no runtime cost, no idea how it works though.
Comments
There is pros/cons to both approaches. The Pipe operator in F# works in conjunction with the HM type inference in the language and static functions often assisting the type checker. i.e. features that work together in a language vs tacked on. F# idiomatic code avoids a lot of virtual dispatch seen in Java/C#, etc as compile time polymorphism is typically how re-use occurs vs objects. I find F# favors compile time abstractions a little more than Scala historically although I note that could be changing.
For most of these proposals it is just syntactic sugar around invoking the function with a placeholder. The pipe in F# is slightly different in that most of the time it has no intermediate lambdas and is compiled in a more performant form. The downside is that unless you allocate that lambda yourself it has to be the last arg. On the plus side like most things in F# it is concise but shows all behavior explicitly - its usually a warning sign if you have to do that and helps reason about performance. Sometimes its a sign that the original function isn't written right or some other inline wrapper could be used for other usages of the function. You can inline a template to rearrange the arg's (inline) to avoid the lambda allocation as well.
This allows some level of re-use and performance benefits avoiding virtual table dispatch and a lambda allocation for many common methods (e.g. map, fold, iter, etc)
I believe the point made in the discussion is that the F# proposal leads to intermediate lambda if the function does not have the right arity. JS also don't do HM so that point is moot.
The people supporting the Hack proposal made the point that their expressions do not desugar to lambda and has no runtime cost, no idea how it works though.