4 ms·

I was hoping to see a mention of Pony which looks like a promising language based on the actor model.

by deckarep 9y ago

adamnemecek 9y ago
Pony does look really solid. It's still new however. Give it 4 years or so.
- krylon 9y ago
  When I took Pony for a test drive, the language itself felt pretty solid; the main obstacle was the tiny standard library. When Pony's standard library grows to a useful size, it's going to be huge. The type system is gorgeous, the documentation is pretty good, and the community is extremely friendly and helpful.
  - mcguire 9y ago
    It sounds like the type system is going to get more featureiferous; my understanding is that they are pushing towards actual dependent typing.
    - adamnemecek 9y ago
      I wish I could target the browser too. Like my biggest problem is writing a front-end and backend in two languages. If I could do both in one, that would be such a killer feature.
      - pmarreck 9y ago
        Clojure and ClojureScript let you do this (albeit in Clojure)
        adamnemecek 9y ago
        I know. I'm rooting for Kotlin for the same reason but Pony does look super promising.
        krylon 9y ago
        IIRC, there is an implementation of Go that compiles to Javascript. https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs I have been meaning to give it a try, but so far I have not found a good excuse to.
Zalastax 9y ago
Personally I'm not too fond of Pony's take on the actor model. I believe it is in the models core that every actor is in total control of their own behavior, and the only interaction is via messages that can be interpreted as the receiver pleases. In Pony, it is the sender that directly commands the receiver what it will do next (via function calls/behaviors).
- mcguire 9y ago
  My take is that you are looking at it the wrong way. Pony uses a single message queue for each actor (which is completely invisible at the code level) and typed messages (which syntactically look like functions). Behaviors (the message handlers) have a lot of limits on them compared to functions (like no return values), so it really is message passing. I'm not sure I really like the syntax that makes messages look like functions, though.
  - Zalastax 9y ago
    > Pony uses a single message queue for each actor (which is completely invisible at the code level) and typed messages (which syntactically look like functions). I totally agree with this definition but believe that it leads to awkward programming. The problem stems from forcing the message queue to be FIFO, which does not always make sense. I think the Erlang style selective receive is the correct abstraction, as it avoids having to maintain a separate queue in userland. I understand why Pony didn't go down that road though, we have a lot more shared experience in type systems for function calling compared to message passing.
mcguire 9y ago
Relating Pony to some of the languages mentioned, two that seem immediately comparable are Akka and Erlang. "Akka’s receive operation defines a global message handler which doesn’t block on the receipt of no matching messages, and is instead only triggered when a matching message can be processed. It also will not leave a message in an actor’s mailbox if there is no matching pattern to handle the message. The message will simply be discarded and an event will be published to the system." "[In Erlang,] receive statements have some notion of defining acceptable messages, usually based on patterns, conditionals or types. If a message is matched, corresponding code is evaluated, but otherwise the actor simply blocks until it gets a message that it knows how to handle." Pony's message passing is syntactically similar to its methods, with a "be" (for "behavior") keyword introducing a handler rather than "fun". As a result, the message receive operation is global, like Akka, but the type system ensures that an actor cannot be sent a message it does not recognize. These are both different from Erlang, which has a local receive operation. An Erlang process, upon receiving an A message, can call another receive statement and block only looking for B messages. At that point, any incoming A messages will queue up. That has always seemed to me to be a good way to write deadlocks without realizing it. Pony is otherwise similar to a typed Erlang that compiles to machine code and doesn't (currently) have process monitoring. [:-(] There was some discussion about distributed Pony, but it has rather strong semantics for message passing, which would require a rather complex underlying protocol. [I'd rather have simple distributed messages and handle failures at the program level.] [I only have experience with Erlang and Pony; I'm hoping my description of Akka is true from the discussion in the post.]
- rurban 9y ago
  Pony is a bit different to a typed Erlang though: * Pony has two message passing options: copy or share (by ref). Both are safe, Erlang does only copy. * Pony is non-blocking only, there are no blocking calls in any stdlib function. * Erlang supports no native threads, only green threads. So it favors IO over CPU, distributed computing on different cores is only via distributed nodes. * Pony supports native threads, but no distributed actors on different hosts yet. * Pony is massively faster, uses much less memory, and has better cleanup via a clever GC protocol.
natdempk 9y ago
I wrote this a little over a year ago, and honestly at the time I wasn't even aware of Pony. However, I am now and will likely revisit this chapter sometime this year as part of work to get this book to some finished state. Not sure whether or not Pony will make it in, but I will definitely think about it more. It is really interesting to see a new actor-model language being developed. I also see that there have been a couple of papers written about Pony, which is a good sign. Definitely on my radar for the future, but I still need to learn more about it.

I was hoping to see a mention of Pony which looks like a promising language based on the actor model.

adamnemecek 9y ago

Pony does look really solid. It's still new however. Give it 4 years or so.

krylon 9y ago
When I took Pony for a test drive, the language itself felt pretty solid; the main obstacle was the tiny standard library. When Pony's standard library grows to a useful size, it's going to be huge. The type system is gorgeous, the documentation is pretty good, and the community is extremely friendly and helpful.
- mcguire 9y ago
  It sounds like the type system is going to get more featureiferous; my understanding is that they are pushing towards actual dependent typing.
  - adamnemecek 9y ago
    I wish I could target the browser too. Like my biggest problem is writing a front-end and backend in two languages. If I could do both in one, that would be such a killer feature.
    - pmarreck 9y ago
      Clojure and ClojureScript let you do this (albeit in Clojure)
      - adamnemecek 9y ago
        I know. I'm rooting for Kotlin for the same reason but Pony does look super promising.
      - krylon 9y ago
        IIRC, there is an implementation of Go that compiles to Javascript. https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs I have been meaning to give it a try, but so far I have not found a good excuse to.

Zalastax 9y ago

Personally I'm not too fond of Pony's take on the actor model. I believe it is in the models core that every actor is in total control of their own behavior, and the only interaction is via messages that can be interpreted as the receiver pleases. In Pony, it is the sender that directly commands the receiver what it will do next (via function calls/behaviors).

mcguire 9y ago
My take is that you are looking at it the wrong way. Pony uses a single message queue for each actor (which is completely invisible at the code level) and typed messages (which syntactically look like functions). Behaviors (the message handlers) have a lot of limits on them compared to functions (like no return values), so it really is message passing. I'm not sure I really like the syntax that makes messages look like functions, though.
- Zalastax 9y ago
  > Pony uses a single message queue for each actor (which is completely invisible at the code level) and typed messages (which syntactically look like functions). I totally agree with this definition but believe that it leads to awkward programming. The problem stems from forcing the message queue to be FIFO, which does not always make sense. I think the Erlang style selective receive is the correct abstraction, as it avoids having to maintain a separate queue in userland. I understand why Pony didn't go down that road though, we have a lot more shared experience in type systems for function calling compared to message passing.

mcguire 9y ago

Relating Pony to some of the languages mentioned, two that seem immediately comparable are Akka and Erlang. "Akka’s receive operation defines a global message handler which doesn’t block on the receipt of no matching messages, and is instead only triggered when a matching message can be processed. It also will not leave a message in an actor’s mailbox if there is no matching pattern to handle the message. The message will simply be discarded and an event will be published to the system." "[In Erlang,] receive statements have some notion of defining acceptable messages, usually based on patterns, conditionals or types. If a message is matched, corresponding code is evaluated, but otherwise the actor simply blocks until it gets a message that it knows how to handle." Pony's message passing is syntactically similar to its methods, with a "be" (for "behavior") keyword introducing a handler rather than "fun". As a result, the message receive operation is global, like Akka, but the type system ensures that an actor cannot be sent a message it does not recognize. These are both different from Erlang, which has a local receive operation. An Erlang process, upon receiving an A message, can call another receive statement and block only looking for B messages. At that point, any incoming A messages will queue up. That has always seemed to me to be a good way to write deadlocks without realizing it. Pony is otherwise similar to a typed Erlang that compiles to machine code and doesn't (currently) have process monitoring. [:-(] There was some discussion about distributed Pony, but it has rather strong semantics for message passing, which would require a rather complex underlying protocol. [I'd rather have simple distributed messages and handle failures at the program level.] [I only have experience with Erlang and Pony; I'm hoping my description of Akka is true from the discussion in the post.]

rurban 9y ago
Pony is a bit different to a typed Erlang though: * Pony has two message passing options: copy or share (by ref). Both are safe, Erlang does only copy. * Pony is non-blocking only, there are no blocking calls in any stdlib function. * Erlang supports no native threads, only green threads. So it favors IO over CPU, distributed computing on different cores is only via distributed nodes. * Pony supports native threads, but no distributed actors on different hosts yet. * Pony is massively faster, uses much less memory, and has better cleanup via a clever GC protocol.

natdempk 9y ago

I wrote this a little over a year ago, and honestly at the time I wasn't even aware of Pony. However, I am now and will likely revisit this chapter sometime this year as part of work to get this book to some finished state. Not sure whether or not Pony will make it in, but I will definitely think about it more. It is really interesting to see a new actor-model language being developed. I also see that there have been a couple of papers written about Pony, which is a good sign. Definitely on my radar for the future, but I still need to learn more about it.