4 ms·

What's a good use for distributed Erlang? I'm writing some Elixir apps, and I can't think of a great reason to use distributed between a client and a daemon ru

What's a good use for distributed Erlang? I'm writing some Elixir apps, and I can't think of a great reason to use distributed between a client and a daemon running on the same box.

spooneybarger 10y ago
One (simplified) example usage: you have an application that you need to scale from 1 BEAM process to more than 1 in order to handle the load. If you are using distributed erlang, sending a message to a remote actor is the same as sending to a local actor and scaling is seamless from the code perspective. Think of having a cluster of BEAM vms that from a programming perspective, you can treat as a single vm.
digitalzombie 10y ago
It's more object oriented don't you think? If you have each part of your code running on different processes, then failures are isolated. Unless I'm reading your question wrong...
59nadir 10y ago
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_applications.html http://erlang.org/doc/design_principles/distributed_applicat...
- amorphid 10y ago
  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.
  - 59nadir 10y ago
    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.

What's a good use for distributed Erlang? I'm writing some Elixir apps, and I can't think of a great reason to use distributed between a client and a daemon running on the same box.

spooneybarger 10y ago

One (simplified) example usage: you have an application that you need to scale from 1 BEAM process to more than 1 in order to handle the load. If you are using distributed erlang, sending a message to a remote actor is the same as sending to a local actor and scaling is seamless from the code perspective. Think of having a cluster of BEAM vms that from a programming perspective, you can treat as a single vm.

digitalzombie 10y ago

It's more object oriented don't you think? If you have each part of your code running on different processes, then failures are isolated. Unless I'm reading your question wrong...

59nadir 10y ago

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_applications.html http://erlang.org/doc/design_principles/distributed_applicat...

amorphid 10y ago
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.
- 59nadir 10y ago
  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.