Actually - thanks for starting this post because while examining the list of purely functional languages that are also by design intended for concurrent programming I came across this which seems very interesting indeed to me:
SeaGraph
erikp33
OTP is the core framework and main value proposition for both Elixir and Erlang. It’s so core it’s part of the kernel. Without OTP Elixir probably doesn’t exist and Erlang is just a weird Prolog variant nobody remembers. It is to Elixir what the DOM is to JavaScript.
On the sidebar: Languages have their purposes and being a pure functional language reference design is not one of Elixir’s. Characterizing Elixir’s diff of Haskell features as a negative or con is misguided and a disservice. Both are functional. Haskell exists to be purely functional at the expense of pragmatism. Elixir exists to be robust, fault tolerant and concurrent at the expense of purity. Being a functional language is a means to an end in Elixir and Erlang, it’s not the reason they exist unlike Haskell. Some of the things you list as negatives are impossible without a static, strongly enforced type system. Elixir has a dynamic, weakly enforced type system.
2
Fl4m3Ph03n1x
Yep, took it. I am now reading an Elixir book ( Which book to read? - #7 by peerreynders ) and I am starting to think that Erlang / Elixir might have been what I have been looking my whole life as a backend developer but never knew existed.
And now that I made my piece with Erlang / Elixir and see it for what it truly is ( concurrency oriented programming language with some FP features ) I am rather excited 
This is mainly thanks to Python’s prominence int he field of AI, a battle ruby lost long ago.
Also, nice list, thanks !
This is exactly how I felt. Still, now I want to learn Elixir’s strengths and I think I will love them. I have already starting to read a book and it sure sounds convincing!
As I have stated before, I now understand that my expectations played quite a role here. Now I understand Elixir’s main purpose and I am already on the learning wagon
3
jeremyjh
This isn’t quite right. Erlang and Elixir are definitely functional languages. Not inspired by, not functional features, but fully functional. There are no loops, no mutable variables, no “classes” or modular state of any kind. Most imperative techniques are simply not applicable. It isn’t pure, but neither are the lisps, and its more functional than most of them.
5
peerreynders
Fl4m3Ph03n1x
Well, let’s just agree to disagree then. No worries, we can still be friends 
Now this is an interesting turn of events
0
jeremyjh
There is no disagreement. I’m simply explaining how these terms are used in computer science and in industry. If you want to use them differently after knowing that, its fine with me.
6
Crowdhailer
Creator of Raxx
That would be a Result monad, (maybe would value | nil).
with is quite along way from a result monad.
OK is closer, because if forces the use of only {:ok, value} | {:error, reason}. It’s what I use and at this point I don’t feel like I’m missing anything more. however all of it’s checks are runtime so if @Fl4m3Ph03n1x is familiar with Result types in other languages might still not regard it as a solution. Combining OK with dialyzer is even better but it’s still a compromise. In the end I have made good use of my functional programming knowledge to work in Elixir but when I miss stuff from other functional languages I just have to remind myself how helpful the process model is.
2
joeerl
Creator of Erlang - Fondly Remembered
The good thing about Elixir (and Erlang) lies in the concurrency - it’s all about creating parallel process and sending messages - and this (as Alan Kay has pointed out on numerous occasions) is the
essence of OO programming.
OO programming is all about objects. Objects are things that respond to messages (or should be) - to get an object to do something you send it a message - how it does it is totally irrelevant - think of objects as black boxes, to get them to do something you send them a message, they reply by sending a message back.
How they work is irrelevant - whether the code in the black box is functional or imperative is irrelevant - all that is important is that they do what they are supposed to do.
Unfortunately the first big OO language based on this model (smalltalk) talked about objects and messages but messages in smalltalk were not real messages but disguised synchronous function calls - this mistake was repeated in C++ and Java and the “idea” of OO programming morphed into some weird idea that
OO programming had something to do with the organisation of code into classes and methods.
Erlang and Elixir support the lightweight creation of millions of isolated processes - everything works by messaging between processes - the design of a system involves observing the concurrency you want in your application and mapping it onto processes.
A web server in Elixir for 10,000 users is not “one web server with 10,000 users” (like Apache or Jigsaw or all the rest) it’s “10,000 web servers with one user each” - this is a radicle departure from conventional practise.
The fact that Erlang/Elixir processes are described in a simple functional language is more or less an accident - they started off in a relational language (Prolog) and C-nodes (for example) can be written in ANY language - the important point about Elixir (and any BEAM) based machine is that the underlying VM can handle extremely large numbers of parallel processes.
For a long time I’ve said “Erlang is the only true OO language” (now I guess I can add Elixir).
The basis of OO programs are:
- isolation between objects (we do this)
- late binding (we decide what to do when a message arrives at a process)
- polymorphism (all objects can respond to the same message, for example, you could
think of sending a "print-yourself" message to any object and it would know how to do it)
Of lesser importance is
- division into classes and methods
- syntax
- the programming model (ie functional or imperative)
Once we have split a system into large numbers of small communicating processes the rest is relatively easy - each process should be rather simple and do rather little wich makes
programming easy.
What Erlang (and Elixir) added to programming was the idea of the link. This was Mike Williams idea - this extends error handling over process boundaries and with links and process we have all we need to build supervision trees and so on.
Supervisors, gen_servers and all that jazz are just simple libraries that hide a bit of detail from the user - they are just built in a rather simple way with links and parallel processes.
Erlang was not designed as a FP language - but as a tool for building long-lived
fault-tolerant systems.
Central to fault-tolerance is the notion of remote error handling. If an entire machine fails the fault must be corrected on a DIFFERENT machine. It cannot be corrected locally because the local machine is dead.
This means that to program for fault-tolerance we need distribution and messaging to be easy to program - so basically any design for fault-tolerance will end up looking like Erlang.
The whole point of Erlang was to make it easy to program fault-tolerant systems, a side effect is that it’s also easy to program scalable systems.
The differentiator between Erlang and Elixir and “All the rest” is the concurrency and fault-tolerence mechanisms - it not about Monads and Syntax and whether it’s a pure FPL.
Now would you like to handle 10,000 users in a single thread using callbacks to emulate concurrency or would you like to make 10,000 concurrent processes, each of which is simple and has no callbacks.
Each process waits for a message that it is interested in then performs a computation and sleeps waiting for the next message.
I think a big problem in evangelising Erlang/Elixir is that you have to explain how having large numbers of parallel processes solving you problem helps. Since no other common languages support concurrency in any meaningful way the need for it is not understood.
“But I can do everything in callbacks in a single thread” they’ll say - and they do - and it is painfully difficult - and you ask “what happens if the callback gets into a loop or raises an exception” - if they don’t understand the question you’ll have some explaining to do - if they do understand the question then you can tell them that in a strange far off land where was a was to program concurrency that did not involve callbacks.
80