Never used akka; but in erlang, actors (processes) are frequently long-lived, which is what he means by "unbounded lifetime. An erlang process generally doesn't

Never used akka; but in erlang, actors (processes) are frequently long-lived, which is what he means by "unbounded lifetime. An erlang process generally doesn't do a single computation and then join back with the spawning process; instead, it usually stays alive as long as the resource it is managing is alive. For example, in a chat server, you might have one process per user, and one process per channel; when someone says something, it's passed via TCP to the user process, which passes it to the channel process, which hands it out to the other user processes, which send it back to their users. Each of the user processes and channel process are long lived; they are there to sit around idle until they need to react to an event, at which point they wake up, do their work, and go back to sleep until another event comes along. Fork-join, instead, is about shorter-lived processes, that are treated essentially as parallel subroutines, and go away as soon as that computation is done. Note that both actors and fork-join may be mapped to long-lived hardware threads, but both are used fairly differently; I see a pretty big distinction between long-lived Erlang actors and short lived fork-join patterns. And of course, you can emulate fork-join with actors, but based on the paper you linked to, it sounds like there might be some efficiency benefits from treating them differently.