5 ms·

If you had to make a comparison, what would be the pros and cons of using elixir vs node.js?

crusso 10y ago
Apart from the other individual language/framework differences others will no doubt give you - Uncle Bob makes some great points on why we should be moving to functional languages: https://www.youtube.com/watch?v=7Zlp9rKHGD4 https://www.youtube.com/watch?v=7Zlp9rKHGD4 To summarize his best point: Processor manufacturers are betting the farm on multi-core. They want to increase performance by giving you more running cores, so you should be using a language that makes multiprocess programming easier. Functional languages, especially ones like erlang, do precisely that.
tabeth 10y ago
What's your use case?
- aecorredor 10y ago
  I know depending on the use case some tools are better than others, but to clarify my original question, for someone who might just be getting into the back-end and looking towards the future, what would be a better choice to focus on, elixir or node.js? and say for example that the person has done both some Ruby and JavaScript programming, including some basic apps with Rails and Express.
  - novembermike 10y ago
    Javascript is a very common language. Elixir is generally a better language, but less popular. If you're looking to get a job you could probably do either but there are probably more Javascript jobs. At the hobbyist level Node might be easier to pick up, especially if you know Javascript already.
    - pythonaut_16 10y ago
      I think Javascript is generally a safe bet for the next few years because the Frontend is firmly embroiled in Javascript as well. Elixir seems poised to keep growing on the backend, so it's probably not a bad one to learn either. My real advice to someone starting out would be to learn a language but focus on learning general programming and computing concepts through it. The better you are at programming and computing, the more easily you can pick up new languages and switch between them seamlessly. Also, as you learn new languages, focus on learning the right way to do things in that language. It's extremely helpful to be able to separate programming concepts from language constructs.
  - jerelunruh 10y ago
    All forward looking statements are guesses but... I see a strong movement toward Elixir from Ruby devs (and others, I'm not a Rubyist) and I expect Phoenix to be one of the main frameworks in the next few years. It's due to a combination of simplicity, history (erlang is old), and a change in the types of apps some of us are building. There will always be simple CRUD apps too but the demand for constant connectivity seems to be rising. IoT, desktop replacement apps, etc. Edit: fixed typo referring to Elixir as a framework
alberth 10y ago
More fair comparison would be Phoenix [1] to node.js Elixir is a programming language whereas node is a framework. [1] http://www.phoenixframework.org/ http://www.phoenixframework.org/
- aecorredor 10y ago
  True, then in that scenario we should talk about comparing phoenix and express right? edit: meant to say phoenix, not elixir.
  - gregdeveloper 10y ago
    Express and phoenix maybe. Elixir is not a framework. Node is to js perhaps as plug is to elixir. Even that kind of doesn't compare correctly though.
    - novembermike 10y ago
      node is to js as beam is to elixir, roughly.
- novembermike 10y ago
  Node isn't really a framework, it's a runtime and is fairly close to a language. It's roughly analogous to Nashorn.
- gregdeveloper 10y ago
  Node is not a framework though
- jnbiche 10y ago
  Node.js isn't a framework. It's a JS runtime, and for most purposes can be considered a variation of JavaScript. However, like Go, Node.js has such a rich networking support in its standard library, that some people go "frameworkless" when developing web apps in Node. But not as many as in Go, probably. Something like Express would be more analogous to Phoenix in Elixir.
joaomdmoura 10y ago
@aecorredor, there a bunch of things you should consider and that I could use to compare both, in general ppl tend to compare elixir with node because it also enables you to build concurrent apps, but you have to take into account the Erlang VM and OTP, the tools it brings to the table to build concurrent system surpass node.js capabilities of delivering the same thing IMHO. Also don't forget that Erlang and it's VM has 30+ years of intense exposure to different scenarios and apps, and put that together with 30 years worth of open source work and libraries. I'm not saying node.js is bad, or even worse, but maybe both shouldn't be compared because represent different tools for different jobs.
andy_ppp 10y ago
It does depend on what you are doing - if you are making websites both are fine (although I've seen callback hell implemented in a Node/express website before). If you have difficult scaling problems that need stateful servers and clever cross server web socket implementations like Phoenix.Presence or 2 million web socket connection on a single huge machine, Elixir with the OTP is more likely to give you tools to build this difficult to scale thing.
vikingcaffiene 10y ago
I'm currently working in both. If we are just talking about them in terms of their respective merits, Elixir is my preference. It has a wonderful compiler, pipes allow for composable chains of logic, the Phoenix framework is wonderful for web development. Literally every interaction with it I've had has made me think "wow that's just a great example of excellent programming taste...". In terms of scaleablilty, I've heard stories of a single server able to handle millions of requests. Not personally been able to verify that (nothing I've done in the language has reached that kind of scale sadly...). Once you get used to pattern matching, you'll wonder how you ever lived without it. The community is amazing and supportive. The language creator Jose Valim has responded to my emails directly which is really cool. 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.
- 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).
rdtsc 10y ago
Elixir (well I use Erlang but it is close enough). * I like the concurrency model better. Lightweight processes vs callbacks and futures. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most modern popular operating systems represent concurrency - an isolated process. * Safety & fault tolerance. Processes are isolated. So you can build very robust systems. That simply puts money in your pocket just due to ops costs. A non-critical / experimental part of backend is crashing at 4am and restarting? No, problem, keep sleeping. Rest of the service will stay up and you can fix it in the morning. * Debuggability and inspection. BEAM VM comes with built in ability to debug, inspect and trace out of the box. That has saved so much time (and money) over the years. * Hot code reload. This is a first class feature. We don't rely on it to do upgrades. But it proved invaluable to fix an issues or two for a high value customer without taking down the services. Or simply to add extra logging to monitor a pathological edge-case.
- innocentoldguy 10y ago
  I think it is important to note that processes are not only isolated at a high level, but also use private memory deep within the BEAM VM; unlike the JVM, for instance, which uses shared memory.
  - rdtsc 10y ago
    Good point. That is why the analogy with the OS processes. They really are the best of both world -- they are lightweight and also have isolated heaps.
outlog 10y ago
these two vids are pretty great, obviously they favor FP/elixir, but great advise from two expert people. Elixir Should Take Over the World by Jessica Kerr: https://www.youtube.com/watch?v=X25xOhntr6s https://www.youtube.com/watch?v=X25xOhntr6s What every Node.js developer needs to know about Elixir - Bryan Hunter: https://www.youtube.com/watch?v=q8wueg2hswA https://www.youtube.com/watch?v=q8wueg2hswA FP and the Erlang VM gives you a great deal of advantages, which you should be aware of. Ultimately I would also look into node.js, since it's so popular it's becoming a reference, and jobs for javascript/node are easy to get.
overcast 10y ago
This biggest pro for node.js, is the large community. JavaScript is everywhere, there is a literally a stable library for anything you can possibly conceive at this point, and if you're already doing front end, it's an easy pickup.
sergiotapia 10y ago
Elixir's greatest strength is it's simplicity with modules and it's functional paradigm. No confusion as to how to import a module and what to namespace it. Just call it. No fuss. Immutability. Your functions returns transformed data, you don't transform the data itself. That's liberating and makes for such a compelling unit testing experience you find yourself writing more tests to make 100% sure that function does what you want it to do and handle edge cases. With Node (Javascript), you don't have that. You have a cobbled together solution that works just barely. But how? I don't know. You npm installed something now the project won't work, you spend three hours debugging and out of desperation you npm install again and now it's working - but why, who knows. Multiply this strange experience to 5 times a day and you get kind of exhausted of Javascript. Maybe it's not Javascripts fault. Maybe it's Node/NPM itself that ruined the experience, I haven't used Yarn yet.
brightball 10y ago
There's a lot of replies to you here but I'm going to touch on the big one. Node.js's biggest concurrency perk is non-blocking I/O thanks to a cooperative scheduler. When I/O is about to happen, the scheduler relinquishes control. Elixir has non-blocking everything. Each process is prescheduled making it impossible for a runaway method to completely takeover the process. The a comparative example server with millions of small requests in each language. An infinite loop in node would disrupt every other request to the server. In Elixir, the other requests would go on as if nothing happened. The tradeoff to prescheduling is that you'll never hit a top end benchmark with Elixir vs other fast languages, but you'll get a very consistent response time. Makes it ideal for real time work, which is what most servers really are. There's many more that other folks are describing here. Natural clustering ability due to lack of shared memory, immutability, message passing, etc. Really cheap processes (goroutine = 2k, elixir process = 0.5k) that makes it so cheap that the model is to create two. One as a supervisor and the other as the actual process. If anything crashes the process, the supervisor instantly restarts it. The combination of the supervisor tree and prescheduling make it possible to run entire applications within the runtime that other parts of the system depend on. Imagine running a database INSIDE of your Node application. Pair that with the natural clustering ability and you get the ideal platform for a self-contained distributed system. Just keep tacking on servers as you grow. You'll hear the term "OTP" a lot and that's essentially a set of patterns on top of the foundation that I just described that provides best-practices and models for utilizing the stack in different scenarios.
- perishabledave 10y ago
  This and the actor model for concurrency goes hand in hand. Not only do you have an pleasant way for writing concurrent software, but you have a foundation (BEAM and OTP) that is built for the concurrency model. From what I've seen, people investigate Elixir for the functional programming but stay for the concurrency.
aecorredor 10y ago
Just wanted to say thanks to everyone who replied. Lots of great advice. Cheers.
innocentoldguy 10y ago
Elixir: 1. Has a better standard library, plus easy access to all of Erlang's standard library. 2. Handles concurrency, instead of having to rely on an event loop, and does so in a clean and accessible way. 3. Makes it easy to communicate between processes, not on the same machine, but processes running on other machines as well. 4. Is faster and consumes less resources. 5. Is easier to create, manage, and maintain code and deployments. My last point is subjective, but I like Elixir's syntax much, much better than Javascript's. In my opinion, comparing Elixir to Node is like comparing a Tesla to a high-end roller skate.

Apart from the other individual language/framework differences others will no doubt give you - Uncle Bob makes some great points on why we should be moving to functional languages: https://www.youtube.com/watch?v=7Zlp9rKHGD4 https://www.youtube.com/watch?v=7Zlp9rKHGD4 To summarize his best point: Processor manufacturers are betting the farm on multi-core. They want to increase performance by giving you more running cores, so you should be using a language that makes multiprocess programming easier. Functional languages, especially ones like erlang, do precisely that.

tabeth 10y ago

What's your use case?

aecorredor 10y ago
I know depending on the use case some tools are better than others, but to clarify my original question, for someone who might just be getting into the back-end and looking towards the future, what would be a better choice to focus on, elixir or node.js? and say for example that the person has done both some Ruby and JavaScript programming, including some basic apps with Rails and Express.
- novembermike 10y ago
  Javascript is a very common language. Elixir is generally a better language, but less popular. If you're looking to get a job you could probably do either but there are probably more Javascript jobs. At the hobbyist level Node might be easier to pick up, especially if you know Javascript already.
  - pythonaut_16 10y ago
    I think Javascript is generally a safe bet for the next few years because the Frontend is firmly embroiled in Javascript as well. Elixir seems poised to keep growing on the backend, so it's probably not a bad one to learn either. My real advice to someone starting out would be to learn a language but focus on learning general programming and computing concepts through it. The better you are at programming and computing, the more easily you can pick up new languages and switch between them seamlessly. Also, as you learn new languages, focus on learning the right way to do things in that language. It's extremely helpful to be able to separate programming concepts from language constructs.
- jerelunruh 10y ago
  All forward looking statements are guesses but... I see a strong movement toward Elixir from Ruby devs (and others, I'm not a Rubyist) and I expect Phoenix to be one of the main frameworks in the next few years. It's due to a combination of simplicity, history (erlang is old), and a change in the types of apps some of us are building. There will always be simple CRUD apps too but the demand for constant connectivity seems to be rising. IoT, desktop replacement apps, etc. Edit: fixed typo referring to Elixir as a framework

alberth 10y ago

More fair comparison would be Phoenix [1] to node.js Elixir is a programming language whereas node is a framework. [1] http://www.phoenixframework.org/ http://www.phoenixframework.org/

aecorredor 10y ago
True, then in that scenario we should talk about comparing phoenix and express right? edit: meant to say phoenix, not elixir.
- gregdeveloper 10y ago
  Express and phoenix maybe. Elixir is not a framework. Node is to js perhaps as plug is to elixir. Even that kind of doesn't compare correctly though.
  - novembermike 10y ago
    node is to js as beam is to elixir, roughly.
novembermike 10y ago
Node isn't really a framework, it's a runtime and is fairly close to a language. It's roughly analogous to Nashorn.
gregdeveloper 10y ago
Node is not a framework though
jnbiche 10y ago
Node.js isn't a framework. It's a JS runtime, and for most purposes can be considered a variation of JavaScript. However, like Go, Node.js has such a rich networking support in its standard library, that some people go "frameworkless" when developing web apps in Node. But not as many as in Go, probably. Something like Express would be more analogous to Phoenix in Elixir.

joaomdmoura 10y ago

@aecorredor, there a bunch of things you should consider and that I could use to compare both, in general ppl tend to compare elixir with node because it also enables you to build concurrent apps, but you have to take into account the Erlang VM and OTP, the tools it brings to the table to build concurrent system surpass node.js capabilities of delivering the same thing IMHO. Also don't forget that Erlang and it's VM has 30+ years of intense exposure to different scenarios and apps, and put that together with 30 years worth of open source work and libraries. I'm not saying node.js is bad, or even worse, but maybe both shouldn't be compared because represent different tools for different jobs.

andy_ppp 10y ago

It does depend on what you are doing - if you are making websites both are fine (although I've seen callback hell implemented in a Node/express website before). If you have difficult scaling problems that need stateful servers and clever cross server web socket implementations like Phoenix.Presence or 2 million web socket connection on a single huge machine, Elixir with the OTP is more likely to give you tools to build this difficult to scale thing.

vikingcaffiene 10y ago

I'm currently working in both. If we are just talking about them in terms of their respective merits, Elixir is my preference. It has a wonderful compiler, pipes allow for composable chains of logic, the Phoenix framework is wonderful for web development. Literally every interaction with it I've had has made me think "wow that's just a great example of excellent programming taste...". In terms of scaleablilty, I've heard stories of a single server able to handle millions of requests. Not personally been able to verify that (nothing I've done in the language has reached that kind of scale sadly...). Once you get used to pattern matching, you'll wonder how you ever lived without it. The community is amazing and supportive. The language creator Jose Valim has responded to my emails directly which is really cool. 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.

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).

rdtsc 10y ago

Elixir (well I use Erlang but it is close enough). * I like the concurrency model better. Lightweight processes vs callbacks and futures. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most modern popular operating systems represent concurrency - an isolated process. * Safety & fault tolerance. Processes are isolated. So you can build very robust systems. That simply puts money in your pocket just due to ops costs. A non-critical / experimental part of backend is crashing at 4am and restarting? No, problem, keep sleeping. Rest of the service will stay up and you can fix it in the morning. * Debuggability and inspection. BEAM VM comes with built in ability to debug, inspect and trace out of the box. That has saved so much time (and money) over the years. * Hot code reload. This is a first class feature. We don't rely on it to do upgrades. But it proved invaluable to fix an issues or two for a high value customer without taking down the services. Or simply to add extra logging to monitor a pathological edge-case.

innocentoldguy 10y ago
I think it is important to note that processes are not only isolated at a high level, but also use private memory deep within the BEAM VM; unlike the JVM, for instance, which uses shared memory.
- rdtsc 10y ago
  Good point. That is why the analogy with the OS processes. They really are the best of both world -- they are lightweight and also have isolated heaps.

outlog 10y ago

these two vids are pretty great, obviously they favor FP/elixir, but great advise from two expert people. Elixir Should Take Over the World by Jessica Kerr: https://www.youtube.com/watch?v=X25xOhntr6s https://www.youtube.com/watch?v=X25xOhntr6s What every Node.js developer needs to know about Elixir - Bryan Hunter: https://www.youtube.com/watch?v=q8wueg2hswA https://www.youtube.com/watch?v=q8wueg2hswA FP and the Erlang VM gives you a great deal of advantages, which you should be aware of. Ultimately I would also look into node.js, since it's so popular it's becoming a reference, and jobs for javascript/node are easy to get.

overcast 10y ago

This biggest pro for node.js, is the large community. JavaScript is everywhere, there is a literally a stable library for anything you can possibly conceive at this point, and if you're already doing front end, it's an easy pickup.

sergiotapia 10y ago

Elixir's greatest strength is it's simplicity with modules and it's functional paradigm. No confusion as to how to import a module and what to namespace it. Just call it. No fuss. Immutability. Your functions returns transformed data, you don't transform the data itself. That's liberating and makes for such a compelling unit testing experience you find yourself writing more tests to make 100% sure that function does what you want it to do and handle edge cases. With Node (Javascript), you don't have that. You have a cobbled together solution that works just barely. But how? I don't know. You npm installed something now the project won't work, you spend three hours debugging and out of desperation you npm install again and now it's working - but why, who knows. Multiply this strange experience to 5 times a day and you get kind of exhausted of Javascript. Maybe it's not Javascripts fault. Maybe it's Node/NPM itself that ruined the experience, I haven't used Yarn yet.

brightball 10y ago

There's a lot of replies to you here but I'm going to touch on the big one. Node.js's biggest concurrency perk is non-blocking I/O thanks to a cooperative scheduler. When I/O is about to happen, the scheduler relinquishes control. Elixir has non-blocking everything. Each process is prescheduled making it impossible for a runaway method to completely takeover the process. The a comparative example server with millions of small requests in each language. An infinite loop in node would disrupt every other request to the server. In Elixir, the other requests would go on as if nothing happened. The tradeoff to prescheduling is that you'll never hit a top end benchmark with Elixir vs other fast languages, but you'll get a very consistent response time. Makes it ideal for real time work, which is what most servers really are. There's many more that other folks are describing here. Natural clustering ability due to lack of shared memory, immutability, message passing, etc. Really cheap processes (goroutine = 2k, elixir process = 0.5k) that makes it so cheap that the model is to create two. One as a supervisor and the other as the actual process. If anything crashes the process, the supervisor instantly restarts it. The combination of the supervisor tree and prescheduling make it possible to run entire applications within the runtime that other parts of the system depend on. Imagine running a database INSIDE of your Node application. Pair that with the natural clustering ability and you get the ideal platform for a self-contained distributed system. Just keep tacking on servers as you grow. You'll hear the term "OTP" a lot and that's essentially a set of patterns on top of the foundation that I just described that provides best-practices and models for utilizing the stack in different scenarios.

perishabledave 10y ago
This and the actor model for concurrency goes hand in hand. Not only do you have an pleasant way for writing concurrent software, but you have a foundation (BEAM and OTP) that is built for the concurrency model. From what I've seen, people investigate Elixir for the functional programming but stay for the concurrency.

aecorredor 10y ago

Just wanted to say thanks to everyone who replied. Lots of great advice. Cheers.

innocentoldguy 10y ago

Elixir: 1. Has a better standard library, plus easy access to all of Erlang's standard library. 2. Handles concurrency, instead of having to rely on an event loop, and does so in a clean and accessible way. 3. Makes it easy to communicate between processes, not on the same machine, but processes running on other machines as well. 4. Is faster and consumes less resources. 5. Is easier to create, manage, and maintain code and deployments. My last point is subjective, but I like Elixir's syntax much, much better than Javascript's. In my opinion, comparing Elixir to Node is like comparing a Tesla to a high-end roller skate.