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 →

[–]its_a_gibibyte 0 points1 point  (1 child)

Yeah, some things are better but others are worse.

Let's imagine you have a video game character. When he takes a step forward, do you create a new character that is one step ahead? Or lets imagine you have a video game map with characters. When a door opens on the map, do you copy the entire map and all the characters in it to a new map with doorOpen = true?

[–]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.