11–20 of 88 posts
I was hoping to see a mention of Pony which looks like a promising language based on the actor model.
> 59 minutes read Is this actually correct? I am inclined to think not but it is difficult to judge just from scrolling through it quickly.
I was hoping to see a mention of Pony which looks like a promising language based on the actor model.
"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.]
Is there an index to this book I'm not seeing? I see the directories, but not seeing an overall index. A bit hard to navigate.
If you click on "Chapters" it takes you to a directory listing of the chapters, click on a chapter link and it takes you to another directory listing of pages. Click on a page link and it takes you to an actual chapter. It appears that the "book" still needs a fair amount of polishing to be navigable.
Is there an index to this book I'm not seeing? I see the directories, but not seeing an overall index. A bit hard to navigate.
They highlight that the hosted site is far from polished but you can always host it yourself ;)
Is there an index to this book I'm not seeing? I see the directories, but not seeing an overall index. A bit hard to navigate.
If you click on "Chapters" it takes you to a directory listing of the chapters, click on a chapter link and it takes you to another directory listing of pages. Click on a page link and it takes you to an actual chapter. It appears that the "book" still needs a fair amount of polishing to be navigable.
Earlier quoted context omitted.
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.
Clojure and ClojureScript let you do this (albeit in Clojure)
I was hoping to see a mention of Pony which looks like a promising language based on the actor model.
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).
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.
I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunderstanding the execution of my own application. Having to take out pencil and paper to reason about why messages are bottlenecking in this component or why I was wrong when I thought I knew how my application worked.
For example, we ripped out all of our channels in our Go application and replaced them with a couple mutexes.
When I read about actors, I get flashbacks to some of my worst struggles with channels. Where our application is split into disparate agents that everyone has to eventually map out on a whiteboard to understand even basic runtime behavior.
I owe it to myself to try it out, but I can't help but be discouraged by what I think they are. Can someone clarify? What does the actor model actually mean for your day-to-day code compared to futures, for example?