It is a stronger form of separation than modularization implies. Each BEAM process has its own isolated memory, and processes communicate exclusively via message passing (not RPC).
"Modules define domains of logic, the scrolls on the shelf. Processes are independent actors, the gnomes who read those scrolls. You can have thousands of workers all using the same code without binding their identity to it."
You are mixing runtime behaviours/memory model with code sharing.
You can share code without sharing instantiation! It does means you have to consider the system dynamic if you allow code change or runtime dynamic reflection, but that is rarely used and when it is, it is because you actively want that behaviour
alper | a month ago
I didn’t expect the metaphor to work but it did.
mtende_kuyokwa | a month ago
Isn't this simply modularization with messages as an interface?
[OP] krig | a month ago
It is a stronger form of separation than modularization implies. Each BEAM process has its own isolated memory, and processes communicate exclusively via message passing (not RPC).
mtende_kuyokwa | a month ago
so this "architecture" can only be used on low level langs?
I mean lets say you have a function in moduleB and you want to use it in moduleA. you need to create a message sharing of some sort?
nbyqvist | a month ago
No. From the article:
"Modules define domains of logic, the scrolls on the shelf. Processes are independent actors, the gnomes who read those scrolls. You can have thousands of workers all using the same code without binding their identity to it."
Diana | a month ago
You are mixing runtime behaviours/memory model with code sharing.
You can share code without sharing instantiation! It does means you have to consider the system dynamic if you allow code change or runtime dynamic reflection, but that is rarely used and when it is, it is because you actively want that behaviour
adamcstephens | a month ago