An interesting thing about Factorio to me (beyond what’s stated in the linked article), is that it contains a nearly a perfect 1:1 analogy to software concurrency.
• Belts are blocking CSP channels, as seen in e.g. Golang (where N producers have to share — or eventually “merge onto” — one channel representing the blocking-receive point of the consumer; which are best only used to transport messages of a single type, or if not, then the sum-typed channel must be demultiplexed at the end, with this tending to lower throughput; where messages of a given type “queue up” until the channel is full, and then all producers block when attempting to write to the channel; where if you’ve got producers producing at different rates, then the fastest ones can hog the capacity of the channel, decreasing throughput and unevenly spending input resources such that some components fail long before others; where the solution to this is to give each producer its own bounded outbox channel that multiplexes onto the consumer’s channel, such that the producer will block itself rather than blocking its siblings; etc.)
• Logistics robots are message-queue topics (where N producers can publish messages of a given type, without worrying about how they’ll get to a consumer; where consumers [demand chests] subscribe to specific event message types; where the bus itself can get overloaded, causing delivery failures of unrelated topics as delivery-threads sit around holding a message unable to deliver it; where the solution to this is to add reliable MQ-internal storage [network-linked storage chests] for the agents to offload produced messages to until demand comes for them.)
(Sadly there’s no exact equivalent to Erlang-style message-passing, where producers target messages of arbitrary type at a specific consumer, which all go to the consumer’s single inbox; and where, if that inbox is full, then the message just “evaporates” en route, since the passed message has async semantics where the producer isn’t linked to its delivery. But, interestingly, that type of concurrency totally could be added, with a not-even-very-complex mod — just add a “outbox” chest object that can be configured to “target” a specific “inbox” chest somewhere else; and a second type of logistics robot that only moves stuff from outbox chests to inbox chests, not according to “demand” but just because anything currently sitting in an outbox chest is “intended to be” in the corresponding targeted inbox chest; and then ensure that this alternate type of logistics robots have non-reliable delivery semantics, where if the “inbox” chest signals to the network that it’s full, then all active delivery-threads targeting that inbox will literally “drop their messages on the ground”.)
IMHO it’s actually possible to learn how to be an effective distributed-systems engineer, just by playing Factorio and trying to scale the throughput of a resource-constrained system. In the process, you’ll likely re-invent many real-world concurrent software design patterns. Doing this first, and then reading a Distributed Systems textbook, will have a much more visceral impact on you, because you’ll have already faced these problems, struggled with them, and now you’re being handed all the techniques for solving them on a silver platter.
I wanted, but never got around to, creating a mod that accepts some kind of data outside the game (lines of text, JSON objects, packets from the TUN driver, whatever), wraps them up as Factorio objects, and plops them onto a belt, and another that reads them and sends them back out.
The idea being that this could be (A) a cool hack (belt speed factoring into ping time, lmao), but (B) a way to visualize data flow in complex queue systems.
Hell, why not turn Factorio into a programming language?
If you can translate a real-world problem to in-game problems, it'd be so much fun to solve them that you'd probably launch a new epoch in human history - the Factorio Age
> (Sadly there’s no exact equivalent to Erlang-style message-passing, where producers target messages of arbitrary type at a specific consumer, which all go to the consumer’s single inbox; and where, if that inbox is full, then the message just “evaporates” en route
Train stations plus circuits can do this. Trains can be configured to leave a station when not empty (after receiving a
message item of any type), and recipient stations can be disabled by a circuit if the receiver is full, causing the train to skip the station. The last station on the train's route would empty it before it goes back to waiting for a message item to deliver.
Not quite the same scheduling/locking semantics, though — sure, it's "concurrent" and packet-oriented, but it's a token ring. It's similar to the original Redis model of concurrency: just have everyone make a series of tiny requests, and then loop around / select(2) from your clients, handling each client's latest request serially, with no request queuing because all requests are synchronous/blocking for the client making them.
N logistics bots are a much closer analogue to N scheduler threads each working in parallel to 1. take a message from a priority heap (really, to take a schedulable process from a priority heap and then run it to produce messages, but same difference) and then 2. synchronously shuttle that message to its destination queue.
I suppose you could get the same semantics with N parallel train tracks, one per scheduler-thread; plus an actual scheduler priority-queue implemented in circuits. But I feel like that's a "non-idiomatic case", in that, no matter how you designed your stations or where you put them, it'd be incredibly painful to design a loader/unloader for a "bus" of parallel train tracks. Especially if all the trains arrive together. It'd be a setup the devs would take one look at and say "that's too much of a kludge, and yet the kludgeyness is necessary, and that's our fault for not including a necessary abstraction. We'll just put in that abstraction."
(The alternative would be a mod that allows trains to pass through one-another on a track. Then you could have one train-line where each train cleanly represents a scheduler thread. No idea what would happen if they tried to stop at the same station at the same time, though. Ghost trains~)
• Belts are blocking CSP channels, as seen in e.g. Golang (where N producers have to share — or eventually “merge onto” — one channel representing the blocking-receive point of the consumer; which are best only used to transport messages of a single type, or if not, then the sum-typed channel must be demultiplexed at the end, with this tending to lower throughput; where messages of a given type “queue up” until the channel is full, and then all producers block when attempting to write to the channel; where if you’ve got producers producing at different rates, then the fastest ones can hog the capacity of the channel, decreasing throughput and unevenly spending input resources such that some components fail long before others; where the solution to this is to give each producer its own bounded outbox channel that multiplexes onto the consumer’s channel, such that the producer will block itself rather than blocking its siblings; etc.)
• Logistics robots are message-queue topics (where N producers can publish messages of a given type, without worrying about how they’ll get to a consumer; where consumers [demand chests] subscribe to specific event message types; where the bus itself can get overloaded, causing delivery failures of unrelated topics as delivery-threads sit around holding a message unable to deliver it; where the solution to this is to add reliable MQ-internal storage [network-linked storage chests] for the agents to offload produced messages to until demand comes for them.)
(Sadly there’s no exact equivalent to Erlang-style message-passing, where producers target messages of arbitrary type at a specific consumer, which all go to the consumer’s single inbox; and where, if that inbox is full, then the message just “evaporates” en route, since the passed message has async semantics where the producer isn’t linked to its delivery. But, interestingly, that type of concurrency totally could be added, with a not-even-very-complex mod — just add a “outbox” chest object that can be configured to “target” a specific “inbox” chest somewhere else; and a second type of logistics robot that only moves stuff from outbox chests to inbox chests, not according to “demand” but just because anything currently sitting in an outbox chest is “intended to be” in the corresponding targeted inbox chest; and then ensure that this alternate type of logistics robots have non-reliable delivery semantics, where if the “inbox” chest signals to the network that it’s full, then all active delivery-threads targeting that inbox will literally “drop their messages on the ground”.)
IMHO it’s actually possible to learn how to be an effective distributed-systems engineer, just by playing Factorio and trying to scale the throughput of a resource-constrained system. In the process, you’ll likely re-invent many real-world concurrent software design patterns. Doing this first, and then reading a Distributed Systems textbook, will have a much more visceral impact on you, because you’ll have already faced these problems, struggled with them, and now you’re being handed all the techniques for solving them on a silver platter.