Erlang concepts of processes, list comprehensions, pattern matching and extremely simple file/socket interfaces just make problem solving a breeze.
There is very little boilerplate and very little in the way of irrelevant details.
There is very little boilerplate and very little in the way of irrelevant details.
I've spent a single day with Elixir and really liked it (if it was statically typed, I would have stuck with it), but I've only ever seen Erlang code (and stack traces), and honestly, the syntax looks really intimidating.
That said, Erlang has Dialyzer, which gives you 'optional' typing. Elixir can make use of it too, though I don't think it's quite as good (though I haven't used it in prod the same way). Basically, it'll walk through your code, infer types, and tell you anywhere the code can't work based on what it could infer. You can help it by adding type annotations as well. So for instance, you read from ETS; Dialyzer will infer it can be type "any". But, what's this, you append to it; it must be a list of some type then. So that place you're multiplying it by a number must be wrong, since you can't multiply a list by a number. But in reality what's coming out is a binary; both operations are wrong. Diyalyzer can't tell you that, but you can tell it that via type spec.
Regardless, I'd probably create new projects in Elixir at this point; mix is such a good tool, and Elixir has some real niceties (looking at you, actual string type and pipe operator), to where it would probably be my default at this point.
Far more Elixir developers I know have just given up on using Dialyzer altogether than the Erlang devs I know.
As for why elixir devs give up on dialyzer, I suspect that sometimes the messages can be cryptic because they are formatted as erlang terms. This is basically now a nonissue due to elixir_ls.