You are correct that it is easier to use functional languages in some domains. There are quite a few messaging clients that use Erlang under the hood. Facebook uses Haskell for its spam engine, where being very explicit about if a long chain of things fails open or closed is important. These days, most of the major programming languages have ways of representing functional elements.
However, it's hard to make functional programming general purpose. There are some posts about it elsewhere, but iterative programming tends to make reasoning about the storage of different objects in memory quite a bit easier. Given how all abstractions are leaky anyhow, there will almost always eventually be some component that is easier to deal with using OOP. The inverse is not necessarily true.
There are some practical considerations here as well. While it's possible to make OOP-esque structures in functional languages, it's not trivial. Meanwhile, using a piece of functional code in an already OOP system generally isn't too bad - there is, once again, some syntactic sugar, but the scope tends to be clearer. Putting a bit of functional code inside say, a class, tends to muck with the usage and assumptions of said class less than putting a bit of OOP into functional code.
> There are some posts about it elsewhere, but iterative programming tends to make reasoning about the storage of different objects in memory quite a bit easier.
Depending on what you mean by "functional", this is not always true. Rust is essentially a functional language - in that, just like functional languages, it prevents you from mixing shared state with mutability; plus it heavily uses functional features like closures - but it makes it quite easy to reason about the storage of data objects.
I view OOP as basically mistaken, particularly wrt. choices like implementation inheritance as an "idiomatic" element of software design. And newer languages like Rust make the exact same choice there. But once you take the trouble to carefully "unpack" stuff like implementation-inheritance, even OOP is quite compatible with a functional paradigm.
Facebook had a working spam classification system, and they replaced the data dependency graph engine with Haskell as a performance experiment. It's not to do with failing open or closed. Note that they hired the inventor of GHC Haskell's concurrency engine to do it, and he is not available to work at the company :-)
Ehhhh I’ve heard the predecessor engine had much to be desired, so it probably wasn’t only just the performance bit. That said, I could see performance (in addition to execution guarantees) being part of the factors.
Sorry, not parsing the last sentence - what do you mean by “he is not available to work at the company”?
However, it's hard to make functional programming general purpose. There are some posts about it elsewhere, but iterative programming tends to make reasoning about the storage of different objects in memory quite a bit easier. Given how all abstractions are leaky anyhow, there will almost always eventually be some component that is easier to deal with using OOP. The inverse is not necessarily true.
There are some practical considerations here as well. While it's possible to make OOP-esque structures in functional languages, it's not trivial. Meanwhile, using a piece of functional code in an already OOP system generally isn't too bad - there is, once again, some syntactic sugar, but the scope tends to be clearer. Putting a bit of functional code inside say, a class, tends to muck with the usage and assumptions of said class less than putting a bit of OOP into functional code.