I looked thru the docs assuming this might run on ERTS/BEAM but it doesn't seem so? Perhaps it is novel?

Personally I really struggle with Erlang syntactically. Elixir is a lot better... but I think Python is the king of syntax.

My biggest problem in life is actually not syntax related - it is "how to architect systems on actors". Writing modules/classes, the implentation, that stuff is really trivial for any decent programmer. The hard part to me is figuring out, how do I map my problem to these actors? How many supervisors do I have? Who supervises who? Transitioning from traditional RPC or process/thread based thinking to actor thinking has been hard for me. I yearn to understand it fully, but I have a block. You could perhaps say the same thing for languages like go and clojure who rely on channels for async communication. In some sense, you can consider a goroutine or a core/async function to be an actor, and the channel is an inbox (broad generalization here). The issues you face adjusting your thinking are similar.

This tool does not solve the aforementioned problem for me, that exists regardless. But I have long thought that Python with a distributed actor model and immutable datastructures that could circumvent the GIL would be the unstoppable language for building modern apps.

Acton has a different focus than Erlang. Beyond syntax, the type system is likely the biggest difference, both in how in feels to the developer as well as what it means for things under the hood. I think Acton, given static typing, can compile down to more efficient code than what you can ever achieve with Erlang. From this perspective, Acton is more in the same camp as Rust or Go. But where Go is a language built around CSP, Acton, like Erlang, is built around the actor model. So if you like actors but also like types, maybe Acton is for you :)

There's lots of work to get types into Erlang, but it's hard to bolt things on afterwards, which is why Acton is a language and not just an actor framework for X.