Elixir and Erlang have a type checker as well. Not Hindley–Milner but one called "success typing" and is checked by a tool called Dialyzer. It is rather good actually:
But is still optional to compile. The more precise and better the type annotations, the more helpful it is. If it can deduce that some inconsistency or type error occurring it will let user know. If it is not sure, it won't say anything.
Another point is because of isolated process heaps and extra fault tolerance, it is possible to get a high degree of assurance from a system built in Erlang or Elixir even with dynamic typing. And there are certainly many examples of that.
Dialyzer is indeed nice, but as you say, it's completely optional, it's not Hindley-Milner, and it relies entirely on thorough, correct type annotations from the developer.
Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit. So I stand by my point that Elixir is a very different language in practice from Elm.
> Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit.
This is not true. While Elixir may not make things as explicit as Elm (I don't know Elm well enough to assert or refute such a statement), the author of Elixir has stated in various occasions that Elixir prefers explicit to implicit.
For instance, in Elixir, unless one explicitly defines a String.Chars protocol for a data structure, string interpolation of that data structure will not compile. In contrast, pretty much everything can be implicitly interpolated in Ruby.
Another example is function calls. In Elixir, if f is not a named function but a variable bound to an anonymous function, you cannot call it by writing something like f(x). Instead, you must put a dot after f and write f.(x) to state clearly that you are calling an anonymous function.
I use Erlang and I like it a bit more than Elixir in general exactly because it is more explicit. It involves slightly more syntax but there is less hidden magic stuff happening behind the scene.
You are right about the type system but still, Elixir is a lighter, friendlier functional programming language compared to haskel or erlang. Not having previous FP experience, I'm having a good time learning Elixir + Elm.
Could you clarify? I don't immediately see the relevance of this. Why does it matter if the compilation target is or is not also strongly typed, and how does that imply anything about the experience of using a high-level dynamically typed language vs. a high-level statically typed language?
I understood the (some number of grands-)parent comment to be saying "Elixir seems a good candidate [for a compilation target]." If that was not your interpretation, then it is certainly non-sequiter. Re-reading, I think I misread something in a surrounding comment, though I'm not sure what.
I said "Elixir seems a good candidate" for backend development, not as a compilation target. The OP asked for suggestions regarding light, friendly FP languages for backend dev.
http://learnyousomeerlang.com/dialyzer
But is still optional to compile. The more precise and better the type annotations, the more helpful it is. If it can deduce that some inconsistency or type error occurring it will let user know. If it is not sure, it won't say anything.
Another point is because of isolated process heaps and extra fault tolerance, it is possible to get a high degree of assurance from a system built in Erlang or Elixir even with dynamic typing. And there are certainly many examples of that.