Elixir looks interesting, but the issues it addresses in Erlang are mostly superficial and subject to taste; eg I like single-assignment, and consider 'nil' a deficiency that can usually be avoided with proper typing. But each to his own -- Erlang does have its quirks, but for me, that mostly fades once you're neck-deep in code.
I'd like to see a BEAM-based language designed with an eye towards advancing the tenet of fault-tolerance in ways Erlang currently can't. Probably the most significant weakness right now is with the type system -- lacking exhaustive checks for pattern and function matching always makes me nervous, since that's probably the most common source of errors in my Erlang code.
Rust looks promising in this regard. If a best-practices framework emerges a'la OTP, Rust is going to be the dream love-child of ML, C and Erlang.
What? Yes, Elixir's syntax is different, but it retains most of Erlang's semantics. And it's not hard to see that Clojure and Java are very different beasts, both syntactically and semantically.
I'm reminded of a talk by Rich Hickey in which he recounts his experiences trying to initially make Java more immutable. He concluded that while it was certainly possible, it was less than ideal and that a language such as Clojure facilitated expressing the semantics he wanted to convey. As a thought exercise, I would have you re-implement Spawngrid's mimetypes[1] library in Elixir to better understand what I mean. Email me at devin@devintorr.es and I can further elucidate.
mimetypes author & maintainer here. If I would ever have a tiny bit more time, I'd rewrite mimetypes in elixir in an instant. The solution we ended up doing in mimetypes, was the greatest fit for Elixir, not so much for Erlang (although, certainly possible — and it is being used by lots of Erlang developers).
I'd like to see a BEAM-based language designed with an eye towards advancing the tenet of fault-tolerance in ways Erlang currently can't. Probably the most significant weakness right now is with the type system -- lacking exhaustive checks for pattern and function matching always makes me nervous, since that's probably the most common source of errors in my Erlang code.
Rust looks promising in this regard. If a best-practices framework emerges a'la OTP, Rust is going to be the dream love-child of ML, C and Erlang.