I've always thought the potential for Erlang technology in game servers is huge (as demonstrated in PikkoTekk - http://muchdifferent.com/?page=game-pikkotekk). Hopefully, _hopefully_, Elixir will go a long way to reducing the perceived barrier.
Negative. Elixir should be no slower than Erlang as it uses the same data types as Erlang. Elixir tuples are Erlang tuples, Elixir function calls are Erlang function calls, etc.
In practice, you may find that your Elixir code is even faster than the equivalent code you might write in Erlang. Elixir encourages some things like compiling some logic into your modules. For example, Dynamo compiles routes so they're super fast. String.Unicode is compiled from the UnicodeData.txt database itself[1].
Dynamo seems to be still pretty early in development. You might want to watch the video linked to the page from the 0redev conference. He doesn't talk about dynamo much, but he does give "2013" as the date for Dynamo.
On the WebSockets issue, I'd check out Cowboy. Cowboy seems to be the new hotness in erlang web apps. It has at least some support for web sockets.
If you're looking for a full featured web framework with built-in web socket support then maybe what you really want is Nitrogen: http://nitrogenproject.com
Finally, and just for completeness, since I'm mentioning web frameworks, you'll probably want to see what ChicagoBoss's WS story is: http://www.chicagoboss.org or if someone's done something with WebMachine and websockets: http://basho.com
I think Nitrogen sounds like the best bet.
Since Elixir seems to mix effortlessly with Erlang, you should be able to write your code in Elixir using any of these frameworks.
I usually really don't like huge web frameworks like Nitrogen. I'll take a look though.
Edit:
Took a look at the documentation. You couldn't pay me to touch Nitrogen. Hopefully Cowboy turns out to be more promising. I'm already familiar with CB.
Weren't all Elixir records using proplists or orddicts? Isn't that slower than your usual data access that doesn't make use of them? Or did you find it had no impact in practice?
This is a somewhat close possibility barring comments, as elixir produces erlang AST.
However, the AST it produces won't be perceived fully idiomatic style-wise (because of how some macros expand) so there might be not much value in this.
Also, without Elixir stdlib, such compilation would be useless as idiomatic Elixir normally includes use of Elixir stdlib.
For me, what makes it safe to adopt Elixir is the fact that worse comes to worse, I still have my .ex sources, they compile to valid beams, why should I care?..
I care about unlikely, but still possible case, when Elixir tools like compiler and libraries, stopped to be supported, while standard Erlang VM and tools continue to evolve.
Today you can compile Elixir source code using --debug-info as an option. Then you would be able to retrieve the abstract format from beam files and write your own code that converts abstract format to erlang source. It is definitely doable and I wouldn't be surprised if someone already did it.
There is no easy way around the chance that some project dies. While José and I pointed that it is quite easy to convert the AST produced by Elixir back to Erlang source (erl_pp?), it might not be the best workaround for the unlikely death of the project. Death doesn't meant the compiler stops compiling :)
I've just recently started working with Elixir for a major project. I actually like the Erlang syntax so don't need Elixir for the syntax, but for some other features that are useful for me.
The community around Elixir is small, but VERY good. Jose Valim is the kind of person who is an ideal community leader, and thus it's great to have him leading this effort.
This is the language that should be getting rockstar status (not Coffeescript, etc.)
Real erlang concurrency + the features Elixir offers makes it unbeatable.
Of course, I admit, I'm still in the "honeymoon" period with the language, so this could be hormones talking.
