Because believe it or not, this is a valid function in Haskell:

Function languages are awesome but the problem is that they are very different from OOP languages, and people have a hard time going from a language like C, Ruby or Python to a functional one.

I would say because OOP makes more sense to a larger group of programmers, since even the underlying machine operates "imperatively" and it's easy to see the benefits of modelling your problem domain in terms of objects similar to the ones in the real world that affect that domain, where functional programming offers benefits that are more "academical" and less easily observable by your average programmer, while the context switch required, in terms of thinking about the problem, is quite severe. (Imagine telling Jim that he cannot mutate the program state, not even talking about monads.)

Another factor is that while Lisp was quite heavily pushed in the hacker community, there was never a company quite the size and marketing power of Sun, as there was for OO.

Most importantly, C was not functional and C touched everything. The extension to OO in the form of C++ was quite straightforward and preserved the performance characteristics of C, whereas Haskell's performance is quite unpredictable to this day.

You don't know what you're getting yourself into with this question, since it might get political very quickly, lol. I am not blaming you, though, we all deserve to know.

One opinionated developer kept telling me that since the humble days of emerging programming languages, a certain company had launched what he called "an attack" on functional programming, and that made OOP prevail. OOP is taught in schools, and usually is the first encounter any new programmer encounters, making them clinch tight to it. That is all to say, OOP is popular because a business wanted to push their product, not because it was better.. That is one opinion.

My opinion would simply be the practical use cases for functional programs are less. Multi-core smart phones aren't new at all, and most frameworks we use to build products are still stuck in the single threaded era, making functional programming less appealing. After all, in functional programming you are incurring a lot of copying thanks to the immutable state of the objects, it might be pointless in a single threaded environment.

Another thing about functional programming that I found annoying was scripting. I love Elixir, but I'll probably use python for scripting small stuff forever, since it's just so easy to preserve an object's state. Or, maybe it is easy for me since I grew as an OOP developer, who knows?

I would like to conclude with a reference to PHP. People love PHP, others wanna burn it to the ground. We can at least agree from that, it doesn't beat other languages in its field if that's the case, and yet... It's super popular.

Elixir isn't so widespread because it's quite new in the scene. And, in the beginning, it targetted an audience which wasn't stacked anymore.

Bringing the Ruby syntax to a fully multi-threaded environment isn't such a hot topic too. JRuby tried, IronRuby tried, Rubinius tried and with Python we have already an established language which looks relatively similar to Ruby and has better performance in many situations.

But Elixir didn't stop at porting Ruby syntax to Erlang. It added pattern matching, immutability, macros and has seamless as well as penalty free interop between Erlang and Elixir code. In contrast, JRuby has a very slow startup performance compared to Ruby but has a better IO performance than Ruby. To use some Java libraries, you have to write code differently than you would do for talking to other Ruby libraries. Elixir doesn't fail on that topic.

Pattern matching together with immutability allows so much better control of data flows. Instead of multiple If-else or switch-case statements you write your conditions line by line. It's clear which condition will pass. No messing around with braces brackets and curlies.

Immutability forces you to think simple. If you get access to a variable, its content will never change while in your hand. No need to think of how when and where to check if a value has changed. Instead, you are dealing with copies, and the Erlang Garbage collector does an excellent job here because dealing with copies sounds like eating memory like crazy. Erlang splits blocks into micro processes, and if a micro process finishes before Garbage collection, memory is discarded for free. It's ultra fast, because no stop the world, compared to JVM and other VMs.

Macros are crazy. Code which writes code. Elixir is written almost entirely from macros. Phoenix (similar to Rails) is also almost written from macros.

Elixir code compiles into BEAM machine code. This format is a native format for Erlang VM. Executing BEAM code allows to call and receive data from other BEAM code based programs. With very few exceptions, Elixir and Erlang programs do not need to know which language was used to generate BEAM from the sources.

Now it's up on us developers to pick up Elixir. Bringing Elixir into bigger companies like it has happened 3-4 years ago with the ​explosion of Node.js.