An actor scripting language?

[Dale Schumacher]

I'd like to explore the design of a simple actor scripting language at the next friam. The goal is to create a language that could allow even non-professional programmers to create effective programs using actors.

The sematics of the language would conform to the Classic Actor Model as described in https://dalnefre.com/wp/2024/04/classic-actor-semantic-model/

The language design starts from the observations in https://dalnefre.com/wp/2020/01/requirements-for-an-actor-programming-language/

In order to avoid bikesheds relating to surface syntax, I'd like to focus on the semantic model of language elements, and the data they require, as specified in an abstract syntax tree.

I'm posting this to give notice to less-frequent attendees that might be interested in this topic.

[Raoul Duke]

> Messages are sent asynchronously

> there is no “return value”

how are message delivery failures to be handled?

[Tony Arcieri]

On Tue, Jan 6, 2026 at 8:01 PM Raoul Duke <rao...@gmail.com> wrote:

how are message delivery failures to be handled?

In Erlang they disappear into a black hole

--

Tony Arcieri

[Dale Schumacher]

The actor message-passing primitive is reliable, asynchronous, and one-way. The Classic Actor Model specifies that all messages sent are eventually received, with a non-deterministic arrival order, at their target. This semantic specification can be achieved if all the actors are within the same failure domain. For comparison, it is normal to expect that "messages" sent to Objects in Smalltalk are not subject to communication failures.

To be clear, this is not a distributed system model. When extending the model over the network, the proxy and stub actors can assume reliable messaging to/from their peers on each end of the connection, but the network hop(s) in between may fail. There are several actor messaging protocol designs that can be used to mitigate and/or handle these failures. Some may involve "reliable" connections between machines, but others do not have such requirements.

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CAHOTMVJ-twW8Xm1%3DJWmpbvJY-KCvfgDEg2Y%2BzcVQvKo%2B6PkUYw%40mail.gmail.com.

[Raoul Duke]

i am mostly ignorant, and my train of thought here is getting OT, rat-holing away from your, "hey, I just wanted to work up a language together." :-)

Async is obviously important, but I wish we had more modeling involved so we could really understand and engineer the constraints and failure modes.

Messages in Smalltalk to me are more like procedural call-return since they are not async afaik? Sure there might be some DNU resolution chain but still basically just sync call-return. Seems like a significantly different thing vs. async. 

If i write a tight loop that DOSs an actor system's async message processing, the whole app exits with OOM or some such?

If i try to do that with sync code, it might fail sooner and closer to the logical source of the cause. Might even have a call stack. 

Even just local async is a can of worms i feel like, pragmatically speaking. It takes all the handwaving that happens in "ship it!" sync code development and explodes it to even hairier levels of potential fail. Sure we all use async/await et. al. in our terrible $day_job languages, but I think we're often waving our hands & getting away with engineering lite, rather than surviving due to principled engineering insight on our code? Modeling is hard.

[Rob Meijer]

That is one of the TODO items for a DSL I'm currently working on. The DSL absolutely isn't pure actor model or "pure" anything, but it inherits this problem very much.

The v0.3 of my language design confirms to the idea that a message sent (in my DSL as an invocation) will eventually be processed, but sending itself can fail with a scheduling_error, what is kind of an exception the sender should handle locally. 

Basically right now it's a runtime level global queue, so no OOM but one DOSing producer van still induce an avalanche of scheduling errors amongst all other producers. 

In my TODO I state that I need to look into small "sending" queues for isolation for v0.4 of my spec. 

It's something that needs serious attention because Carl identified reduction of latency along critical paths as one of the main tools for performance, and adding extra sending queues increases latency, and I already have small "keep the event loop busy" queues. And also because right now one actor has the possibility to dominate the scheduling queue (or actually more of a scheduling in memory graph db, but that's not relevant for the discussion).  So I likely need to add extra queue like structures to my main queue-ish scheduling DAG.

While I don't have the option for my DSL, a pure language can I think be synchronous on a small send queue, what in the majority of sends would be effectively asynchonous.

My DSL has an escape hatch that while there are no return values, completion can be awaited, and I could extend that to scheduling being independently awaitable, but that would really clog down the whole fire and forget part of the language. Hence it's very much a TODO item for me that I'm ignoring untill I have a running 0.3.

But as said, a pure actor language could create a hybrid synchronous asynchonous model around short send queues, where sends are asynchonous only if there is room in the send queue.

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/friam/CAJ7XQb4MzYhJK5Du%3DXa53y%2Bco59FtV%3D6GktUfKenU11J6K%3DPFA%40mail.gmail.com.

[Dale Schumacher]

I'm not going to try to justify the Classic Actor Model here. The focus of my topic for friam will be "what are the minimum mechanisms needed in an actor scripting language for beginners to write real programs". The resulting language would be used to write tutorials for uFork and programs in the playground.

To view this discussion visit https://groups.google.com/d/msgid/friam/CAMpet1X6M96%3DKWz5WRVZHhaXFTUaWSu5upc4X4vWfccTsEy-HA%40mail.gmail.com.