Hacker News Reader

Comment by pmarreck | Hacker News Reader

> Functional non-mutating patterns in JavaScript and Python can be substantially, sometimes catastrophically, less performant than the procedural/imperative mutating equivalents

What portion of this is due to the fact that you're using a functional pattern on an imperative language? For example, none of those attempts can take advantage of any underlying purely functional data structures (see: Erlang/OTP/Elixir, or Clojure)

View on HN

Case in point: Tail Call Optimization has been part of the JS spec since ES6, but remains completely unimplemented in all mainstream browsers/engines besides Safari[1]. For all but the most predictable inputs, you're pretty much forced to use loops due to potential overflows in situations where recursion might otherwise be preferable.

More fuel for the pyre: async Iterables cannot be consumed as a piped stream. You must use the for await construct, which is a shame considering the FP niceties that the Array type already provides for more traditional lists. Once again, one is forced by the API to use an imperative construct unless they specifically want to invite trouble by converting it into an Array (... and potentially choking in the process)

[1]: https://kangax.github.io/compat-table/es6/

In practice I feel like recursion isn't actually used that much in functional languages. Most things can be expressed as maps, flatmaps, folds, etc

It depends on the domain. For example, recursion can be extremely useful when processing a tree of data.

Reply on news.ycombinator.com