kll

I think a lot of these things sort of come-for-free when you are an actor based language. Like actors are basically little processes communicating with each other, so you've mostly already abstracted away from memory pointers on your local machine, thus, it's trivial to move an actor to a remote computer but continue communicating with it in largely the same fashion. Clearly you need to be wary of latency but otherwise it looks about the same. Actors are single-threaded and have their own private state, so upgrading an actor is "just" replacing old code with new code but the same private data. You don't have to synchronize this access with other threads or similar. Actors just make this easier, which is why you'll probably find such features in languages using actors.

Acton has its own run time system though which shares much more with Pony than with BEAM. Pony folks wrote a paper on distributed computing with actors - https://www.doc.ic.ac.uk/~scb12/publications/s.blessing.pdf

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.

Much like C abstracts over machine code or Python over C, Acton attempts to provide abstractions that let you treat multiple computers connected together in a distributed system, as a single logical machine, much like programming your own local computer. This is what the "made easy" alludes to.

Acton leans heavily on actors and actors are already like small little processes that do their thing. With a distributed run time system, we can spread actors across multiple computers, yet let them communicate to each other, much as if they were on the same computer.

Yes indeed, assigning really turns into an await on an async value. You can explicitly write it as

    a = await async remote_actor.foobar()

So the local actor goes to sleep, awaiting the remote, then the RTS notices the returned value and place the actor on the readyQ for execution, thus waking up from the await.

It is not ERTS / BEAM. Acton has its own run time system. Acton code is compiled to C functions, so the execution of functions look quite different between BEAM and Acton RTS. Acton has a Pythonic syntax but is NOT Python, so there is no GIL - quite the contrary, the Acton RTS runs actors concurrently.

I'm afraid that Acton in itself won't teach "how to architect systems on actors". I do wholeheartedly relate to the challenge. It's not easy to switch and think "natively" in a new paradigms. Go try it out, do Advent of Code in Acton and see how it feels ;)

It's not currently pluggable but there are quite few interaction points between RTS & DB so I imagine it could be done relatively easily. Depending on what you want to do, this might work well or become ultra-slow ;) Acton persists the execution of individual continuations (like actor methods but chopped up at every I/O point), so if you write functions in certain ways, you end up with many commits and if the database is not super fast, this can become a real chokepoint.

There are design for how to improve this in Acton through batching and asynchronous commits.

Yes, it does affect the local control flow. If you don't assign the return value, then the local actor will proceed execution of the next thing, so effectively async execution of the remote method call. You can also write this explicitly like so:

    async remote_actor.foobar()

If you on the other hand want to wait for that remote actor to finish but still not assign locally you can use a dummy variable:

    _ = remote_actor.foobar()

or explicitly ask to await

    await async remote_actor.foobar()

You can also explicitly ask for async while grabbing the return value, which makes it easy to run things concurrently

    a1 = async remote_actor1.foobar()
    a2 = async remote_actor2.foobar()
    print("a1 and a2 run concurrently")
    r1 = await a1 # collect both results
    r2 = await a2
    print(r1, r2)

It's about the same in Acton

    message = "hello world"

message is a `str` since we know the literal "hello world" is a str. Some literals can be multiple types, like 123 can be `int` or `u64` or some other fixed int type.

You can specify the type explicitly if you want to

    # some fictional function I just came up with
    def install_requirements(dependencies: set[str], opts: dict[str, str]):
        run_setup(dependencies, opts)
        return assert_requirements_installed(dependencies)

which makes it easier to read the code which is a little bit more involved. It also helps guide the type inferrence & checking. Hindley-Milner type checking is notorious for doing a good job at type unification and a lousy job at error messages. Acton is no exception and is arguably worse than many other users of HM implementations since it is relatively young and all effort have gone into actual type checking and not much into errors.

Broadly speaking, I think the modern solution to IDE insight into types is to implement an LSP that provides types and other information to the editor. Acton does not have an LSP but it will.