34 ms·

Actors + type safety is a huge selling point for Pony that, to my knowledge, no other language is really providing. I'm definitely keeping an eye on it and I'm

Actors + type safety is a huge selling point for Pony that, to my knowledge, no other language is really providing. I'm definitely keeping an eye on it and I'm very excited to see its development continue.

jeremyjh 10y ago
The distributed-process (Cloud Haskell) library gives you Erlang-style processes/actors in Haskell. Haskell is a good language to map these concepts to since it already has lightweight threads, pattern matching, asynchronous exceptions and other language features required to faithfully implement Erlang semantics. Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model.
- 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.
  - 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/
- tormeh 10y ago
  >Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model The actor model is asynchronous by definition. Did you maybe intend to say something else? What makes Erlang different is that the BEAM VM is made for the actor model, so it has per-actor GC and other things that are basically impossible in other languages that don't use BEAM.
  - phamilton 10y ago
    I think if you replaced "an async model" with "a shared event loop" I agree with the expressed frustration.
  - jeremyjh 10y ago
    Erlang and Haskell give you a sequential programming model for I/O (and everything else) within each actor process. You can read from a file, take a result from it, do a database query then post a message to another process. In Akka, you must use asynchronous I/O directly, or use a thin abstraction such as Futures with monadic bind to accomplish the same thing. Under the covers, the Haskell and Erlang runtimes are handling this for you so that you can forget about the fact that you are doing async I/O. In Akka, if you don't pay attention to this and use a non-NIO Java library to do I/O, you will block the entire scheduler. Whereas, every library in the Erlang and Haskell ecosystems already uses the async I/O abstractions in the runtime.
  - Matthias247 10y ago
    > The actor model is asynchronous by definition For sure the independent execution of the actors internal logic is a fundamental property of an actor system. However I think communication APIs between actors don't have to be asynchronous by definition: In Akka they are, because blocking threads woul kill the performance. In Erlang synchronous communication between actors works fine. The C# Orleans framework also favors "synchronous" communication - yes, actor communication returns Task<T> results which can be awaited, so it's async unter the hood - but I consider that an implementation detail). Pony in contrast leans to purely async APIs. There's no way to actively wait for a response from another actor. The advantage is that deadlocks are not possible at all, whereas with synchronous actor communication you can deadlock when 2 actors are waiting upon each other. The drawback are callbacks and the need to model everything as a state machine.
didibus 10y ago
There's Fantom, a JVM based language with baked in actor model. I guess Scala should count too, to some extent.

jeremyjh 10y ago

The distributed-process (Cloud Haskell) library gives you Erlang-style processes/actors in Haskell. Haskell is a good language to map these concepts to since it already has lightweight threads, pattern matching, asynchronous exceptions and other language features required to faithfully implement Erlang semantics. Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model.

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.
- 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/
tormeh 10y ago
>Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model The actor model is asynchronous by definition. Did you maybe intend to say something else? What makes Erlang different is that the BEAM VM is made for the actor model, so it has per-actor GC and other things that are basically impossible in other languages that don't use BEAM.
- phamilton 10y ago
  I think if you replaced "an async model" with "a shared event loop" I agree with the expressed frustration.
- jeremyjh 10y ago
  Erlang and Haskell give you a sequential programming model for I/O (and everything else) within each actor process. You can read from a file, take a result from it, do a database query then post a message to another process. In Akka, you must use asynchronous I/O directly, or use a thin abstraction such as Futures with monadic bind to accomplish the same thing. Under the covers, the Haskell and Erlang runtimes are handling this for you so that you can forget about the fact that you are doing async I/O. In Akka, if you don't pay attention to this and use a non-NIO Java library to do I/O, you will block the entire scheduler. Whereas, every library in the Erlang and Haskell ecosystems already uses the async I/O abstractions in the runtime.
- Matthias247 10y ago
  > The actor model is asynchronous by definition For sure the independent execution of the actors internal logic is a fundamental property of an actor system. However I think communication APIs between actors don't have to be asynchronous by definition: In Akka they are, because blocking threads woul kill the performance. In Erlang synchronous communication between actors works fine. The C# Orleans framework also favors "synchronous" communication - yes, actor communication returns Task<T> results which can be awaited, so it's async unter the hood - but I consider that an implementation detail). Pony in contrast leans to purely async APIs. There's no way to actively wait for a response from another actor. The advantage is that deadlocks are not possible at all, whereas with synchronous actor communication you can deadlock when 2 actors are waiting upon each other. The drawback are callbacks and the need to model everything as a state machine.

didibus 10y ago

There's Fantom, a JVM based language with baked in actor model. I guess Scala should count too, to some extent.