FP's better if you'd rather troubleshoot performance than troubleshoot bugs.
FP langs with good type systems (OCaml, Scala probably, Haskell, Erlang to an extent with optional analysis) permit you make checks early and then have islands of safe and [Haskell has left this sentence] readable code where you know you don't have to have paranoid checks for out of bounds data because the type says that it's in bounds.
All FP langs tend to have garbage collection (the cancer therapy from the 60s, not quite a cure), lots of higher order functions, immutable data structures, etc.
Of the languages listed, OCaml is terse yet readable and is a prince of all trades, proving that people who say "the right tool for the right job" of programming are just people who know a lot of shit languages with narrow utility. OCaml has real success with Jane Street: youtube.com
Of the languages listed, research at Ericsson said nice things about the size and bugginess of Erlang. Although Erlang definitely isn't useful for everything, it's just fucking magic in its own domain and its had success all over the place, in big pozzed companies and small companies and personal projects on a Zaurus running OpenBSD. Here's another single example for it: Vendetta Online uses it. The biggest flaw of Erlang is that it has two string types and the natural default of them is a list of 64-bit ints. Elixir probably goes far to fix that, by making the other type the natural default.
honestly Elixir looks like shit to me vs. Erlang, just in language aesthetics, but you probably won't agree.
Is FP Niggerlicious?
His pants are sitting disturbingly low...
Are you angry because you cannot into FP?
the more difficult languages in OP's picture are difficult because of their defects, not their FP-ness.
You really don't want to go too far into the FP meme. If you even understood half of the terms in that post, you'd know that too.
Brainlets think FP is a brainlet filter though. Their perspective is intrinsically limited to that which is hard for a brainlet, so they project it on everyone else.
It is easier to prove things about the program.
It is easy to create abstractions that make problems easier.
They typically come with a powerful type system,
With strong enough types you can even automatically generate functions. For example if you know you have a function of type a -> a, then it must be the id function. It is IMPOSSIBLE to create any other function with type a -> a which is not the id function.
in Haskell such a function could have an unsafe* function in it that performs arbitrary IO
in OCaml such a function could use Obj.magic and such to return garbage of type a; or inspect the type and have type-dependent behavior
in ATS you can use templating or overloading to have an a -> a that behaves different for different actual types.
in a dynamic language like most in the OP's pictures, of course, IMPOSSIBLE guarantees like this rarely come up.
meanwhile, wow what an amazing thing, something that's probably id by its type. I guess you're not jealous at all of dependent type systems.
General opinion on Elm as a front end web language?
idk about the other languages but the unsafe* functions you refer to are not a part of Haskell. It's a GHC thing.
I'm actually more interested in linear types than dependent types, but dependent types are cool since you can write proofs with them. Well you can write more complicated / actual useful ones with them.