Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>> but that's quite different from a web server that can usually be scaled horizontally pretty easily

So a lot of the other responses are comparing it against Rails and the like, but it sounds like you may be asking specifically around scaling.

Erlang (and by extension, Elixir), is nice even when scaling because the actor model will scale to I/O or CPU bound workers simply, without having to tweak threadpools or worry about thread starvation or etc. Other languages that provide n:m concurrency here have the same benefit though (i.e., Golang).

Where it shines in comparison to those is in its fault tolerance and memory model. Immutable non-shared data + supervisor hierarchy gives you tools to tackle state that are less error prone than most other languages.

And the fact it has a Rails like environment in Phoenix (and Plug, and Ecto, and the whole ecosystem) means you get the same quick-to-build app functionality, without giving up the performance and state management.

It's basically having all of these that make it desirable on this front; you can write code as quickly and simply as in Rails, getting the braindead simple scaling behavior of any actor/CSP based model, with the state management of an immutable language, and the fault tolerance of Erlang.



Not that concerned about scaling - I think it's going to beat Rails there, but for a larger web app growing quickly, the difference between going to N web servers from 1 might not be that many months.


Oh, sure, Erlang isn't going to save you from going multi-node...in fact, it shouldn't; just basic resiliency should mean you're starting multi-node.

But the actual number of concurrents per instance, and the effect on latency, is quite another thing.

And it also provides you a better story around shared state within the instance, and better controls around its access.




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

Search: