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

Why are you specifying that they're on the same box? You can use distributed erlang between different computers and the messaging remains the same even in those circumstances.

On top of that you also get automatic failover for distributed apps(0) that are supposed to run on only one node at a time, handled entirely by the runtime, with takeover, etc.

If you're using Elixir, you should probably actually read up on the technology you're using. These are basic concepts explained in, for example, "Programming Erlang".

0 - http://erlang.org/doc/design_principles/distributed_applicat...



I've got an Elixir app running as a daemon to manage cleaning up some certain build related files for a build system. The daemon is a release started by the init system. N clients might call the daemon, and the daemon makes sure the files needed for the build, or maybe left over from the last build, or in the correct state. The client could talk to the daemon via a socket or TCP port, but distributed Erlang would also be an option.


I would say when it comes to client-server interaction in Erlang, it's fine to make that as if it were any other language, but there are plenty of situations where you'd like to spin up several nodes of something in AWS, for example, and those would necessarily have to talk to each other.

You'll set up the ability for them to coordinate (by simply setting their longnames and setting them all up to connect to one machine, making them create a mesh network) and transparently you'll now have several machines working on something as if they were one, with minimal effort on your part.

The big downside to using distributed erlang is that it has very little to offer in terms of security. If you don't add something yourself (which admittedly isn't too hard) you'll be relying only on a common password for connecting to the mesh, as well as knowing which machine to connect to. Obviously it makes for a situation where it's best and most appropriate to use on your private network, setting up other means of communicating with public networks.




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

Search: