At Bleacher Report, we've definitely reduced operating costs on some of our services by switching to Elixir and running on fewer/smaller machines, and we routinely pick Elixir for new services now. But we also recently launched a Node service which could handle all frontend traffic on a single server, so in some ways it's hard to say whether the gains are more due to the technology or improvements in the service design.
This can lead to a more complicated architecture than with Elixir, where a single Elixir process will be able to use more RAM & all the cores, too.
On the other hand, I love the dynamism of the Elixir ecosystem, but it's not yet as rich as Node's one, and it's still harder to find a proficient Elixir developer, than a Node one.
But personally yes: the fundations of Elixir are very, very strong, and I'm investing in it completely (in addition to Ruby & Node, which I already use).
1. Node has a lot of packages to be sure, but a lot of them are redundant, and a lot of them are packages that overcome some weakness in the Javascript standard library. Elixir doesn't have as many duplicates in its ecosystem, and its standard library is robust enough that you don't have to search for packaged one-liners to overcome some missing feature that should come standard with the language.
2. Node has access to Erlang's standard library and packages. It is also trivial to include external Erlang code and libraries in an Elixir application.
2/ Did you mean "Elixir has access to Erlang ..." rather than "Node...", I assume?
I'm well aware of that (I also use Java libraries quite a lot with JRuby etc, similarly), yet having worked with Erlang developers (in polyglot apps), I still personally find that there is more choice for me in both Node & Rubygems, compared to raw Erlang, at least for the topics we had to cover.
Well - I guess it depends on what your actual needs are, YMMV!
> where a single Elixir process will be able to use more RAM & all the cores, too.
I think you mean a "single instance of the BEAM" here as a single Elixir process is pegged to 1 CPU core.
With Node, you can cobble together pretty much everything I've described (except for maybe pattern matching) above but it's a bit of a kluge IMO. You can program functionally. And you can make yourself a kind of "compiler" via linting or perhaps by using Flow or Typescript. I've yet to find the experience fluid or pleasant. The language is just not designed for that stuff. ES6 is a huge improvement that said. And before you go thinking I am a node hater, I love JavaScript and use it all the time. I'm just painfully aware of its shortcomings because of how much I work with it.
My biggest issue with Elixir is that it's hard to set up a proper CI/Deployment pipeline. It CAN be done and I've done it but nothing "just works" like it does with Node. Try dockerizing a phoenix app or setting up a heroku instance to see what I mean. All of these things work but it's an obscure language so one needs to be more advanced to understand and address problems in that area.
To sum up: very excited about Elixir and hope it continues to grow. If I was starting a new project I would probably use it.