4 ms·

> Each command being a concurrent actor-process would make a lot of sense to me. I've tossed around doing MUDs in Elixir before. I'm not familiar with MOO tho

> Each command being a concurrent actor-process would make a lot of sense to me. I've tossed around doing MUDs in Elixir before. I'm not familiar with MOO though. State has to be owned by a process - who owns the state of the world? Process per "thing" is too fine grained - you're going to have race conditions and deadlocks. Process per "room" can work, but it's still not easy. There are still some cross-room coordinating actions you need to tighten up, and this makes general scripting very hard. Keep in mind, when data is passed "between" processes it is deep copied. This can be a big problem depending upon your process model and how many things your players can carry around. As an experiment I made my own software transactional memory. It worked, assuming no network partitions, but designing and testing it to work in an environment with those was beyond me.

intelVISA 3y ago
> As an experiment I made my own software transactional memory. It worked, assuming no network partitions, but designing and testing it to work in an environment with those was beyond me. BFT STM is a noble goal and, tbh, building performant fault tolerant atomic transaction systems outside of C++ must be quite challenging with all the abstractions atop it
derefr 3y ago
> State has to be owned by a process - who owns the state of the world? ... Keep in mind, when data is passed "between" processes it is deep copied. The Erlang runtime has other stateful things besides processes, and manipulating data within these and/or getting a handle on data in these places doesn't necessarily involve copying. • ETS tables, which hold state privately to themselves (with copying in/out) in a similar way to how processes do. If you manipulate data inside ETS tables by "sending compute to data" (think Redis INCR) rather than by "sending data to compute", then no copying happens. • "Globals" in the form of data compiled into read-only versioned modules loaded into the modules table and available to be referenced from any/all active processes, only copied if the module gets unloaded before the process dies. (Originally this was just a design pattern — https://github.com/discord/fastglobal https://github.com/discord/fastglobal — but it eventually became its own runtime feature in Erlang 22, https://www.erlang.org/doc/man/persistent_term https://www.erlang.org/doc/man/persistent_term). • Large binaries (anything over 64 bytes) aren't allocated in an actor's memory arena, but instead are allocated in a special global-per-node binaries heap, and then ref-counted, where each actor-process holds one reference to each large-binary it's using, and then each read-only slice of that binary, in turn holds a reference to the per-actor reference handle for the binary. One clever technique for sharing a large "database" of data between many actors, is to store the data encoded in a large binary in an encoding that is efficient to partwise-decode; and have the "lookup" operation just parse+decode the appropriate data out of the binary. (This is how erlang:module_info/2 used to work — the global modules-table itself holding a set of references to the loaded modules' binaries, which module_info would then parse metadata out of on demand.)

intelVISA 3y ago

> As an experiment I made my own software transactional memory. It worked, assuming no network partitions, but designing and testing it to work in an environment with those was beyond me. BFT STM is a noble goal and, tbh, building performant fault tolerant atomic transaction systems outside of C++ must be quite challenging with all the abstractions atop it

derefr 3y ago

> State has to be owned by a process - who owns the state of the world? ... Keep in mind, when data is passed "between" processes it is deep copied. The Erlang runtime has other stateful things besides processes, and manipulating data within these and/or getting a handle on data in these places doesn't necessarily involve copying. • ETS tables, which hold state privately to themselves (with copying in/out) in a similar way to how processes do. If you manipulate data inside ETS tables by "sending compute to data" (think Redis INCR) rather than by "sending data to compute", then no copying happens. • "Globals" in the form of data compiled into read-only versioned modules loaded into the modules table and available to be referenced from any/all active processes, only copied if the module gets unloaded before the process dies. (Originally this was just a design pattern — https://github.com/discord/fastglobal https://github.com/discord/fastglobal — but it eventually became its own runtime feature in Erlang 22, https://www.erlang.org/doc/man/persistent_term https://www.erlang.org/doc/man/persistent_term). • Large binaries (anything over 64 bytes) aren't allocated in an actor's memory arena, but instead are allocated in a special global-per-node binaries heap, and then ref-counted, where each actor-process holds one reference to each large-binary it's using, and then each read-only slice of that binary, in turn holds a reference to the per-actor reference handle for the binary. One clever technique for sharing a large "database" of data between many actors, is to store the data encoded in a large binary in an encoding that is efficient to partwise-decode; and have the "lookup" operation just parse+decode the appropriate data out of the binary. (This is how erlang:module_info/2 used to work — the global modules-table itself holding a set of references to the loaded modules' binaries, which module_info would then parse metadata out of on demand.)