I suppose the concurrency model of Erlang is a departure from The Way Things Are, but I'd argue that's a good thing. The JVM doesn't offer much fundamentally different in terms of the concurrency model than Ruby and Python. It certainly performs orders of magnitudes better, but it's still subject to a lot of the same issues: you have a pool of threads running your http service, and when you exhaust that pool then you have outages. And stopping the world for GC is enormously problematic. Erlang takes care of all that in an extremely elegant way.
Also it doesn't take minutes (!!!) to compile an Elixir (or Erlang) program. Developer happiness is often overlooked (Scala being the worst offender in my experience) and Elixir really hits that out of the park.
Scala is definitely C++-esque in being a bloated language. And it lets developers commit utter horrors. But if you stay away from those horrors (mostly new operators and DSLs) and don't use them yourself, it seems like a very nice and elegant language. You get the same functional programming and actor concurrency you would get form Erlang and Elixir.
It's odd at first, but has a few things going for it:
* Its rules are consistent.
* There are few keywords and symbols.
* Once you understand it, you see that pattern matching on function heads or case statements is exactly the same as if/else statements.
* Its standard library contains code that does a lot of the low-to-mid-level stuff you find yourself doing.
* OTP provides nice templates for server-ish things and FSMs, as well as some nice conventions that get followed by a lot of Erlang software.
I know they're not common in modern HLLs since we have magic do-everything array ADTs, but I find it kind of hilarious to describe (singly-)linked lists as "esoteric."
Personally, I enjoy having (really cheap) lists around, and wish more HLLs had them as one of their fundamental, low-level abstractions. There's something extremely satisfying about accumulating elements backward by consing, and then reversing at the end. I'm always worried in Ruby/Python that push()ing elements onto an Array might do all sorts of stupid re-allocations at just the wrong time; lists, on the other hand, have extremely obvious time-space complexities for all their operations.
That's something that can be said about all the Erlang ADTs, now that I think about it—each one has been carefully considered such that you can guess the time/space complexity for each operation and be correct. Erlang (and Elixir) also has a policy that if two ADTs both have an operation with the same semantics, but the two operations have different complexities, then the two operations will get different names—which is amazing for making bad ideas (like trying to do random-access on a list) obvious.
(And really, while we're on the subject, it's tuples that are the weird Erlang type. As handy as they are as an underlying implementation for records et al, there isn't really much theoretical basis for having a set of N fixed-size non-enumerable product types, each with integer-indexed, untyped slots.)
Elixir also has a supremely powerful and elegant macro capability that lets you build really powerful DSLs. For example, chunks of the language are written as Elixir macros -- the if 'keyword', for instance. As a programmer, you have full access to the very same macro system. Writing an unless 'expression' isn't even that hard.
phoenix's use of Elixir's macro system is part of why phoenix can feel so much like rails.
And yes, from the fragments I've seen of Erlang, the two are completely different. What Elixir wants from Erlang is primarily the VM and the OTP libraries.
If you've seen Erlang and it scares you off Elixir, you've got it all wrong.