I find this to be largely untrue. There are certainly classes of algorithms and data structures that benefit from mutation for performance reasons, but at that

I find this to be largely untrue. There are certainly classes of algorithms and data structures that benefit from mutation for performance reasons, but at that point you can simply implement mutation in your pure functional language (e.g. with monads). Even ignoring that case, there are a great many data structures and algorithms that don’t meaningfully suffer from a lack of mutation at all, especially when the compiler is able to leverage assumptions from being in a pure language. This is born out in practice where Haskell for example may not necessarily out perform highly optimized C, but it is frequently able to keep pace with Java and will almost always beat imperative python code. In terms of being concise it’s laughable to me to even make the comparison. I’ve written a lot of C, Python and Ruby in my career in addition to Haskell, and Haskell wins on expensiveness to such an absurd degree that the comparison feels unfair. The one area that I think FP, although really Haskell in particular, suffers is being to reason about. Performance and memory usage of course are notoriously hard to reason about in lazy languages, but it can also be challenging to understand what’s happening in large code bases that may have some deep MTL stack or be using multiple interpreters over some free monad, since the semantics of how computations are being evaluated can often be defined very far from the computation itself.