2 ms·

Yeah the whole actor thing is kind of orthogonal to the question of how you handle the shared world state (which is what makes a MOO a MOO.) There are parts of

Yeah the whole actor thing is kind of orthogonal to the question of how you handle the shared world state (which is what makes a MOO a MOO.) There are parts of my runtime that look Erlang-ish, Actor-ish, because that's a concurrency pattern that Rust does well with, in general. In the end a MOO is just a database with fancy stored procedures. And the original code is not a particular... good one. Handling serialization conflicts is what databases have to do as one of their core abilities, and LambdaMOO just tries to punt on the whole question.

smirya0 3y ago
how did you come to pick Rust (just curious, vs Elixir, Java with Loom, etc)?
- cmrdporcupine 3y ago
  These days Rust is both my day job language (I work on systems for autonomy in tractors) and my hobby language. It's my preferred tool. I have attempted similar systems in C++ before, and got fairly far along at times. But Rust really solves a lot of problems, I tear my hear out a lot less. This is a "systems" type of application; this is a database and compiler and a virtual machine and language runtime. I'm not super concerned with optimization at this point, but I will likely have to be at some point. Being closer to the metal is key for me on a project like this. I'm likely to e.g. rip out RocksDB and replace it with my own database engine at some point (something I work on here and there as another side project, unpublished still.) I will also likely need a better garbage collection solution. With Rust I have options. The community of libraries available for Rust is good. The right tools are there. And the language is expressive enough to make it work well. That said, I have mulled writing the "host" portion -- the layer that manages network sockets and web endpoints, in Elixir/Erlang: The 'daemon' portion of the system sits behind an RPC layer built around ZeroMQ -- so that layer can be restarted/upgraded without losing active network connections. Or can sit on a separate machine for scalability reasons, etc. So it's entirely possible to split what I'm calling the "host" (network facing layer, what we used to call a "frontend" when I worked at Google, but most people think of that term as referring to a UI layer) from the backend "daemon." Anyways for me this project ties together a bunch of interests in systems programming I've had for years. It becomes a kind of synthesis project.

smirya0 3y ago

how did you come to pick Rust (just curious, vs Elixir, Java with Loom, etc)?

cmrdporcupine 3y ago
These days Rust is both my day job language (I work on systems for autonomy in tractors) and my hobby language. It's my preferred tool. I have attempted similar systems in C++ before, and got fairly far along at times. But Rust really solves a lot of problems, I tear my hear out a lot less. This is a "systems" type of application; this is a database and compiler and a virtual machine and language runtime. I'm not super concerned with optimization at this point, but I will likely have to be at some point. Being closer to the metal is key for me on a project like this. I'm likely to e.g. rip out RocksDB and replace it with my own database engine at some point (something I work on here and there as another side project, unpublished still.) I will also likely need a better garbage collection solution. With Rust I have options. The community of libraries available for Rust is good. The right tools are there. And the language is expressive enough to make it work well. That said, I have mulled writing the "host" portion -- the layer that manages network sockets and web endpoints, in Elixir/Erlang: The 'daemon' portion of the system sits behind an RPC layer built around ZeroMQ -- so that layer can be restarted/upgraded without losing active network connections. Or can sit on a separate machine for scalability reasons, etc. So it's entirely possible to split what I'm calling the "host" (network facing layer, what we used to call a "frontend" when I worked at Google, but most people think of that term as referring to a UI layer) from the backend "daemon." Anyways for me this project ties together a bunch of interests in systems programming I've had for years. It becomes a kind of synthesis project.