> Erlang can kill a process, but does not have cancellation, which causes a process to be halted and throw a cancellation exception from the point at which it w

> Erlang can kill a process, but does not have cancellation, which causes a process to be halted and throw a cancellation exception from the point at which it was halted so that clean up can be performed while unwinding. Typically you implement the callback terminate/2 in a genserver. If the process is hopelessly locked, you don't get to do the cleanup you want. It's usually not a big deal, though, because your processes are usually "owner in name only" for any given contentious resource, and a well-designed interface to a contentious resource uses what erlang aptly calls "resources", that lets the VM itself manage cleanup when the owning process dies. In the end, this leads to cleaner code, because you don't even have to worry about cleaning up (I almost never clean up tcp sockets, SSH connections, or file descriptors, because the VM does it for me and knows exactly when to do it). I am writing a native code interface, and the same can easily go from a non-erlang OS thread, by hooking in the correct "resource" adapters, I can have OS thread lifecycle well-managed by the already robust OTP system. > Erlang does not have an assignment command, Erlang programs often use helper processes to temporarily hold state. It actually kind of does. For the sorts of things you seem to be talking about, there is a process-bound k/v store that you can use to sneak some statefulness in. It's totally not talked about much because it's dangerous, especially for beginners, but it's useful when you know that the lifetime of your value is specifically bound to the lifetime of the process. In Elixir, this process k/v store is used, for example, to register in a side channel a "callers" and "ancestors" tree; when you're running tests, this lets you for example, run concurrent database tests transparently associated with the test process, that are also associated with a database transaction, so you can have concurrent database actions which are sandboxed to their own view of the universe. Some libraries even let you encode this into an http request so that your request can leave the VM, return back into the VM, and maintain its sandbox id and database association on the other side of the request. All of this is managed with about two lines of code provided out of the box in the gold standard database library. Prof Hewitt: I don't think erlang is a "true actor system" but I think it's much easier to code without errors than you may think.