Channels are Actors

24 points by carlehewitt ↗ HN
I highly recommend Simon Fowler's ECOOP 2017 lecture https://www.youtube.com/watch?v=lpbkIjjoMRk

However, channels are best understood as Actors with put and get messages so that aChannel.put[x] puts x in aChannel and aChannel.get[ ] gets from aChannel. A channel of type T has the following interface: Interface Channel<T> put[T] -> Void, get[ ] -> T

Actors can be categorically automatized, which means that up to a unique isomorphism, there is just one model that satisfies the axioms. In this way, Actors can be much more precisely defined in a general way than can be done using an extended lambda calculus as in Fowler's lecture.

Furthermore, a common misunderstanding is that an an Actor must have a mailbox, message queue, or event queue. There would be an infinite regress if any of these were required because since everything is an Actor, each of these would itself need a mailbox, message queue, or event queue. Instead, an Actor (e.g. a ReadersWriters scheduler) performs internal queuing when required. See https://www.amazon.com/Inconsistency-Robustness-Studies-Logi...

To get the latest, see my upcoming Code Mesh Keynote: https://plus.google.com/+CarlHewitt-StandardIoT/posts/BXSZ7Y...

18 comments

[ 2.9 ms ] story [ 44.0 ms ] thread
A channel can behave like an actor but they are not the same thing. An actor is a living entity. A channel is a transit mechanism.

What is the purpose of this post? To argue the academic definition of channels and actors? To spark a discussion on their uses and benefits?

It's worth noting that the submitter of the post is also the inventor of the Actor Model.
Fowler's talk addressed issues arising from "mixing metaphors" by having both channels and Actors in our programming languages.

The point of this post is to point out that channels are best understood as Actors that take put and get messages thereby achieving a unification in our programming languages and conceptual framework.

Of course, a channel can be conceived as a "living entity" and an Actor can be used as a "transit mechanism."

"Actors that take put and get messages" – makes sense.
Do you want to abolish the protagonist role of the channel abstraction like in CSP based languages and certain message brokers?

We can't have issues with channels if we're all actors and don't impedance mismatch the mixture when building our systems.

Message passing communication is more fundamental than channel commutation.

However, lists {T*] of type T are very important; especially when they are used with Futures.

> What is the purpose of this post?

To advertise Code Mesh:

> To get the latest, see my upcoming Code Mesh Keynote:

You can watch the keynotes for free after the conference :-)
PS. The interface for ReadersWriter is

Interface ReadersWriter read[QueryRequest] -> QueryResponse, write[WriteRequest] -> Void

A ReadersWriter scheduler for a database allows multiple read messages to be concurrently operating in the database but a write excludes all others.

This appears to be a post about a mystery programming language.
Bigger than that is a concurrent model of computation!
The Actor Model covers all digital computations. Actor programming languages can express all computations in the Actor Model.
How this view on channels relate with information theory? can we think of them as an actor and its capacity a property of the physical modeling represented by that actor: floppy disk, cd, dvd, lan, wan, river, lake, ocean?
I assume you're referring to the Actor model actors not the constrained implementations in popular frameworks, am I right?
Correct.

Current implementations are inadequate :-(

There is a Silicon Valley startup working on one that should be adequate :-)

In almost all current frameworks. every Actor has a mailbox. It makes very good sense for an Actor programming language not to have mailboxes built into every Actor because it can make programs less robust, more difficult to understand, and more difficult to optimize. Instead, when desired an Actor can do its own internal queuing as necessary.