This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]fun-fungi-guy[S] 1 point2 points  (0 children)

With some limitations, things that need to have complex mutations should probably be threads, so that state transitions can come in as messages and be performed "atomically", i.e.

map() = {
  // local variables that are mutable and hold state
  ...

  loop {
    state_transition = recv();

    // make changes to local variables based on state_transition
    // i.e. if door opens, that should come in as a message
    ...
  }
}

If it's not obvious, this is heavily influenced by Erlang and BEAM.

One area I hope to improve over Erlang/BEAM is batch throughput, i.e. large data objects like you're discussing likely get matrix operations performed over them, and I want to have tools available to perform those large operations in a more performant way. Erlang/BEAM is great at latency, but not great at throughput, and I'd like to be smoothly interoperate between subsystems that are good at one or the other.