[yshalabi]

Yes. Functional languages are amenable to composition. Because of their "purity". This allows trivial extraction of parallelism/concurrency. No need to reason about interleaving and shared data and such.

But, I don't know if "use FP if you want parallelism" is an acceptable solution currently. My intuition is that latency sensitive application can't use these languages because they don't expose the low-level primitives (read pointers) that make the difference in such applications. But I haven't written and profiled enough FP code to know if this is absolutely the case.

[zaphar]

No, Functional languages reduce the problems surface area but they don't eliminate it. You can still get data races and deadlocks in Haskell. They aren't the same as a memory race in say C where the contents of a variable might change out from under you in truly bizarre ways but you still get algorithmic races where the wrong answer comes our the other end because two parallel operations happened in the wrong order.

[marcosdumay]

You can't get deadlocks and data races on pure code.

Once your code is in a monad, every one of those problems may be back (including memory race).

[elihu]

The IO monad in particular. Monads by themselves don't introduce races/deadlocks.

[rthomas6]

>two parallel operations happened in the wrong order.

I thought separate functions weren't allowed to have dependencies like this?

[taeric]

Simply put, not everything is commutative.

[codygman]

In regards to pointers and pure functional languages:

https://ghc.haskell.org/trac/ghc/wiki/StaticPointers