Earlier quoted context omitted.
As with most things in Erlang; if it's important, you must make it explicit. Implicit ordering works in your fork-join example with only a single fork, but if you require an ordering, you must be explicit about passing information through to enforce the ordering you need. If you instead did fork { sort a } fork { sort b } a' = join b' = join you would have the same problem as in Erlang. or you could have actor C sort…
> you would have the same problem as in Erlang Ah but that's not how fork-join works - you fork multiple jobs, and then you must join them all at the same time - you can't join just one. You have to do something like (a, b) = join
If you have to join all the the jobs at the same time (which is pretty inflexible), how is the ordering of the results determined? My exposure to this model was in the perl threads module (and the forks module which offers the same api with os forking instead), where you join on a specific thread id, so you can easily enforce ordering by first joining a, and then joining b; I assumed a join with no parameters would join a thread that's ready and/or wait for the first to become ready, because that seems like the most useful/basic interface, and anything more specific (like join all the threads, or join the threads in some order) could be added as needed in the context where it's needed.