Hacker News new | past | comments | ask | show | jobs | submit login

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.




You mention setting up a Phoenix app in Docker so I'll link to a couple of posts I wrote describing how I do that: https://dev.bleacherreport.com/starting-a-phoenix-project-wi..., https://dev.bleacherreport.com/brunch-in-a-container-phoenix.... I almost always start new Elixir projects in Docker for local development now, and deploy the images to Elastic Beanstalk. If you're not setting up a cluster it's not a bad option.

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.


Thanks for the links! I've successfully Dockerized Elixir apps now but I'm always looking for new and better ways to do things. I'll check your stuff out and see how my approach stacks up. Thanks again!


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


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


I 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!


Yeah, sorry about the typo. I did mean that Elixir has access to Erlang...


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


It'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.


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


Regarding CI/CD pipeline. I found SemaphoreCI pretty nice. It supports Elixir/Erlang without the need for Docker and can deploy to Heroku pretty painlessly using the available buildpack. Got a full pipeline working for a Phoenix app going in about 30mins.


Yeah I started off using that exact pipeline and it worked well. We ended up moving to AWS which Semaphore only supports if its Elastic Beanstalk (could be different now to be fair). We couldn't go that route for more reasons than I care to list here. My hope is that Elixir gets popular enough that we can start to see some first class build tools integrated into more of these products.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: