4 ms·

I think there is some misunderstanding of what Pony is. It doesn't target distributed systems by the looks of it, it's more like a statically typed OO language

by zzzcpan 10y ago

I think there is some misunderstanding of what Pony is. It doesn't target distributed systems by the looks of it, it's more like a statically typed OO language with an alternative to threads/mutexes/channels. So you can see it being interesting to people with statically typed OO background, who understand the downsides of multithreading and want concurrency and parallelism on a single system, i.e. those coming from languages like Java and C++. It's more appropriate to compare it with Rust or Go, but not Erlang or Akka.

spooneybarger 10y ago
I'm not sure why you would say that Pony doesn't target distributed systems. In the sense that there is no "distributed pony" yet, then yes. I spend my days writing a soon to be open sourced distributed system in Pony. The "alternative" to threads/mutexes/channels is actors which from a concurrency model perspective makes it very like Erlang. The GC model is also very like Erlang. In the end, it is its own thing.
- amorphid 10y ago
  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.
jeremyjh 10y ago
I think the actor model is orthogonal to distributed systems. Actors are a good model for concurrency in a single system or a distributed system. Just like lots of people build distributed systems in C++, Java or Go, there are a lot of people using Erlang in a single node application.
hellofunk 10y ago
No need to leave c++ for great actors: https://actor-framework.org/ https://actor-framework.org/

by zzzcpan 10y ago

spooneybarger 10y ago

I'm not sure why you would say that Pony doesn't target distributed systems. In the sense that there is no "distributed pony" yet, then yes. I spend my days writing a soon to be open sourced distributed system in Pony. The "alternative" to threads/mutexes/channels is actors which from a concurrency model perspective makes it very like Erlang. The GC model is also very like Erlang. In the end, it is its own thing.

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

jeremyjh 10y ago

I think the actor model is orthogonal to distributed systems. Actors are a good model for concurrency in a single system or a distributed system. Just like lots of people build distributed systems in C++, Java or Go, there are a lot of people using Erlang in a single node application.

hellofunk 10y ago

No need to leave c++ for great actors: https://actor-framework.org/ https://actor-framework.org/