I'm personally still waiting for the JIT. I guess it will be a while.
I couldn't agree more. I have a lot of hope for BEAMJIT (or anything that will make Erlang faster per clock cycle).
http://blog.erlang.org/My-OTP-21-Highlights/
After reading the link above, I get the sad feeling that a faster Erlang isn't anytime soon :(
With that being sad, Elixir has brought a whole new wave of people to the OTP community. Which excites me tremendously. I just hope a faster Erlang will arrive soon enough so that people needing to leave Ruby due to slowness have a good alternative with Erlang.
Also, while additional performance never hurts, the slowness in the Erlang case is really a different kind of a problem than it is in Python or Ruby. Erlang's performance requirements are closer to those of BASH and other shells: there is no need, and no expectation, to have all the code in Erlang. The variety of options for integrating other languages should make this obvious. Even if in general Erlang is rather unimpressive in terms of performance (I'm trying to be diplomatic here...), it does have a couple of highly optimized parts, like the IO, context switching or message passing - in other words, the optimizations are focused on the things that make Erlang special and that other languages generally don't focus on. It makes Erlang often "worth it" even despite the slowness, and it works well in practice, in my experience.
Elixir makes it a bit more awkward. On the one hand, it's a nice language, which is general-purpose enough to look reasonable as an implementation language for most anything. On the other, no matter the amount of pre-computations and clever macrology, it shares the same fundamental limitations that Erlang has - like a lot of copies of everything or non-inlineable calls due to how modules are made reloadable - and it's going to lead to a lot of frustration and emotional rants from people who actually tried to use it as a "reasonable, general-purpose" language without the required preparations. Even when the JIT arrives, it's not going to fit all the performance profiles equally, and the need to carefully consider the performance you need won't disappear.
Compared to other languages, such as Go, Python, Rust, etc, the conceptual models in Erlang (processes, message passing, supervision trees) and how they all work, map better to the web problem domain.
As far as the slow parts, like you said, there are plenty of choices of integrating other languages.
Until then, I'll happily use: https://github.com/hansihe/rustler for writing NIFs in Rust.