4 ms·
I'm working on both too, and one point that I faced was the Node 1.5GB RAM limit per node process (at least on Heroku https://devcenter.heroku.com/articles/node
by thibaut_barrere 10y ago
I'm working on both too, and one point that I faced was the Node 1.5GB RAM limit per node process (at least on Heroku https://devcenter.heroku.com/articles/node-concurrency https://devcenter.heroku.com/articles/node-concurrency - I know it can be worked around though, although not on Heroku), which can force you to run multiple processes (aka clustering) depending on your use cases (e.g. thousands of client websockets connections from the process, if you need to listen to a large number of e.g. Slack connections).
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).
- bhelx 10y agoGood points! > 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.
- akeating 10y agoIt's useful to think of the work of m Elixir processes being distributed to n cpu cores by the BEAM scheduler. An Elixir process is not a system process in the way we usually think of the word process if coming from a non-BEAM world.
- thibaut_barrere 10y agoSorry for the confusion ; by Elixir process I meant a "unix Elixir process" (aka one command you run), not the lightweight Elixir "Process". The unix Elixir process uses multiple CPUs.
- innocentoldguy 10y agoI would disagree with the notion that Elixir's ecosystem isn't as rich as Node's for two reasons: 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.
- thibaut_barrere 10y agoI definitely agree with 1/, yet I was more referring to more advanced functionalities (but I do agree that the "foundations" of Elixir are very strong and I think it will ultimately be a large factor of its success). 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!
- innocentoldguy 10y agoYeah, sorry about the typo. I did mean that Elixir has access to Erlang...