kll

5 ms·

1.
by kll 2y ago
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 l
2.
by kll 2y ago
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 comp
3.
by kll 2y ago
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 l
4.
by kll 2y ago
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
5.
by kll 2y ago
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
6.
by kll 2y ago
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
7.
by kll 2y ago
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 explicit
8.
by kll 2y ago
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 fi