FP languages tend to consider correctness first, but treat performance, and predictability of performance, as second grade citizens. By performance, I mean both

FP languages tend to consider correctness first, but treat performance, and predictability of performance, as second grade citizens. By performance, I mean both time and space, aka cpu and memory. Cpu is bad, but Memory is by far more critical. This makes it tricky to correctly anticipate the outcome of a bunch of lines of code. One also needs to worry about the compiler, how it will interpret that, and this can be hard. Worse, the compiler's interpretation can change with a different version, or following a tiny source code modification that looked harmless. No one likes wild performance swings for no good reasons. Add to that picture layers of abstraction that make debugging an executable more difficult, lack of choice and capabilities in said debugging tools (generally justified by "my code never has any bug!"), and it makes developing a headache, at least when things start to go awry. I haven't even started with 3rd party library supports, etc. On top of that, one rarely codes in the void : a source code is going to be shared with a "community", so it's not a solo choice. One cannot impose a rarely used FP language to a team that know another language very well, and has never asked to change that. Don't get me wrong, I love FP languages, and I can even see how some of their best concepts are being "borrowed" (ha!) by more declarative languages. That may be the best outcome. Maybe in the future, the differences will be less pronounced, the same way as RISC and CISC architecture have largely merged nowadays to inherit the best parts of both sides.