My experience is exactly the opposite: in number crunching it's often easier to parallelize processing in a low-level language such as C or C++. Current C compi

My experience is exactly the opposite: in number crunching it's often easier to parallelize processing in a low-level language such as C or C++. Current C compilers make loop parallelization via OpenMP. And since data is mutable, you do not have the overhead of allocating new chunks of memory (plus garbage collection). Functional languages will eventually be able to do most parallel computations on vectors and matrices nearly as fast as C. E.g. in Haskell a new project has started for adding support for SIMD intrinsics. Packages such as repa have been shown to be much slower (see the repa papers), where a program using repa with 8 cores (without SIMD) has about the same performance as a single-threaded C program (with SIMD). With SIMD support, Haskell plus repa will probably get a lot closer to the performance of C. Where functional programming with immutable data structures does help tremendously is in concurrency. Anyone who has written a fairly complex C++ program using concurrency, such as a GUI application, has probably run into complexity issues. There is a lot of mutable state, and no clearly defined model of interaction between threads. Anyway, in my opinion the real benefit of a pure functional language is that code written in a functional language is often more succinct and easier to reason about. There is no state outside a function (either global or within an object), side-effects are controlled and typing provides neat abstractions (monads, functors, etc.). The primary source of complexity in some functional languages is laziness.