The biggest obstacle to erlangs adoption is that it does not have a low barrier to entry. The syntax is strange, the way of structuring and building solutions is strange. It is incredibly powerful, but it requires a different way of thinking.
Elixir makes sense because it is a lower barrier to entry. This is a very important factor. It is one of the main reasons why node.js was so successful in reaching a large audience. It is why Go is more popular than Erlang. They are often used in the same domain and Erlang is arguably more powerful. People still choose Go however.
I will agree that Elixir has better tooling around building and releasing code.
However, in terms of barrier to entry for developing in, I actually think Erlang's is lower. People tout Elixir for its syntax being similar to other languages, but that's a detriment, not a benefit. Erlang and Elixir, both, require you thinking in a way most other languages don't. With Elixir, and the language looking familiar, you're tempted to try and shoehorn your existing knowledge, practices, etc, into an Elixir shaped package, and that leads to less idiomatic code, more surprises in how things actually work, and sometimes even more brittle applications than how they ~should~ be (though having a decent supervision tree means they'll probably still be better than what you'd have had in those other languages). Using Erlang, though, you relearn from scratch. It's a small language and that syntax isn't really a huge barrier; being forced to code in a language that shares so little with what you're experienced with means you're likely open to new paradigms, and will pick them up instead of trying to reuse your existing ones.
At least, that was my experience with Erlang, compared with Scala/Akka (which I tried first, and ended up with a lot of OO, non-functional, non-parallel code).
I had a similar experience with both Erlang and XSLT -- they don't look anything like a typical imperative language, so I wasn't tempted to think in imperative terms. I just had to do things "the Erlang way" and "the (crazy) XLST way."
I studied prolog too! For a semester only but I loved it. I don't remember much of it but I loved it because it felt like a true "high level" programming language to me. Describe it a problem and ask questions. Felt like magic.
Also learning erlang was much easier when you had some basic idea of prolog. Clauses did not seem so weird and once you understood how clauses work you've basically got 80% of the language nailed.
What I don't really understand though is why erlang didn't go all the way. Why take only surface level features of prolog and ignore the really cool parts?
Erlang vaguely looks like Prolog, but it has semantically nothing in common with it. Even the syntax is quite different beyond base similarities to predicates.
I think it isn't outlined very well in the article. For the most part though I'd say it's syntax and I agree that syntax matters. Elexir is probably a lot easier to stomach than Erlang for many people that started learning in a similar looking language. I think aesthetics matter quite a bit. If I find code strange to look at I'm never fully comfortable with it (this fades over time but I feel it pretty strongly whenever I dive into a new language). This might be silly but from experience students that are exposed to Java first (which is the most common case here) tend to struggle with JavaScript (pre ES6) just because some patterns look "odd".
The Elixir devs are also fairly smart people and the community seems cool which shouldn't be underestimated.
That being said I have a Prolog background so stock Erlang looks fine :D
In addition to the full access to the rich erlang eco-system, elixir also comes with its on rich features like macros which shines through in the design of Phoenix, its major web framework
1. Readability is probably the biggest reason. I don't have to worry that some base object changing what I am thinking is happening. There is little magic and it is easy to follow.
2. Let it fail, elixir and erlang you have to write code assuming it is going to fail and handling when it does. Most other language you have to write that code all over in your logic code. Elixir and erlang you do not (readability again).
3. OTP! There is a great distributed framework that erlang and a bunch of much smarter then me programmers built over the last 20 year that I just get to use. Also you can send functions and code over the wire as well to run. Making some very interesting things that are just impossible to do in other languages.
These are just a few reasons. I do build mostly build web applications for business apps. So because of that this is a really good fit. I don't think it is the answer to all but it has been expanding fast.
The one thing I wish it had would be that your dependencies were yours only. I think this is one of the big reasons Node.js got successful so fast. In node you can run different versions with-in the same app depending on the libraries. Elixir is more like ruby in that you can only have one. Well you can have two for swapping out without down time but that is it. I do think this is one of the limits to the Erlang VM.
> Also you can send functions and code over the wire as well to run. Making some very interesting things that are just impossible to do in other languages.
Well, you could do this in any language that has 'eval' really, which includes most dynamic languages. Unless you're referring to something else?
Erlang provides location transparency for processes, meaning that you can send a message to a Pid (process identifier) as if it were running locally, when in fact it's running on another VM on another machine.
I can't speak for Go, but Elixir has a much more sane concurrency model when writing web services (or otherwise) than node. The ability to block a process means you don't need to dork around with callbacks or promises or anything, your code looks like it executes in serial. No shared memory either, so one request can't break another.
The set of abstractions OTP provides map onto web services perfectly. Once you write stuff in erlang/elixir going back to another paradigm is really quite hard.
