8 ms·

definitely! Reminds me of the golang saying > Don't Communicate by Sharing Memory; Share Memory by Communicating https://www.php.cn/faq/1796714651.html https:

definitely! Reminds me of the golang saying > Don't Communicate by Sharing Memory; Share Memory by Communicating https://www.php.cn/faq/1796714651.html https://www.php.cn/faq/1796714651.html

tombert 1y ago
Yeah, similarly, Joe Armstrong (RIP), co-creator of Erlang explained it to me like this: > In distributed systems there is no real shared state (imagine one machine in the USA another in Sweden) where is the shared state? In the middle of the Atlantic? — shared state breaks laws of physics. State changes are propagated at the speed of light — we always know how things were at a remote site not how they are now. What we know is what they last told us. If you make a software abstraction that ignores this fact you’ll be in trouble. He wrote this to me in 2014, and it has really informed how I think about these things.
- throwawaymaths 1y ago
  The thing is that go channels themselves are shared state (if the owner closes the channel and a client tries to write you're not gonna have a good time)! Erlang message boxes are not.
  - deleted 1y ago
    [deleted]
  - kbolino 1y ago
    You don't have to close a channel in Go and in many cases you actually shouldn't. Even if you choose to close a channel because it's useful to you, it's not necessarily shared state. In a lot of cases, closing a channel behaves just like a message in its queue.
  - tombert 1y ago
    Strictly speaking they’re shared state, but the way you model your application around channels is generally to have independent little chunks of work and the channels are just a means of communicating. I know it’s not one-for-one with Erlang.
  - Kubuxu 1y ago
    You can think of closing the channel as sending a message “there will be no further messages”, the panic on write is enforcement of that contract. Additionally the safe way to use closing of a channel is the writer closing it. If you have multiple writers, you have to either synchronise them, or don’t close the channel.
    - throwawaymaths 1y ago
      Sure but the fact that it is shared state is why you can't naively have a go channel that spans a cluster but Erlang's "actor" system works just fine over a network and the safety systems (nodedowns, monitors etc) are a simple layer on top.
- aatd86 1y ago
  Isn't entanglement in quantum physics the manifestation of shared state? tongue-in-cheek
  - psychoslave 1y ago
    Maybe. Or maybe we observe the same point of information source from two points which happen to be distant in the 3-coordinates we are accustomized to deal with, but both close to this single point in some other.
    - aatd86 1y ago
      but that still means that there is shared state on the projection from the higher tensor space. orthogonality needs to be valid for all subspaces.
gpderetta 1y ago
> Don't Communicate by Sharing Memory; Share Memory by Communicating that's all well and good until you realize you are reimplementing a slow, buggy version of MESI in software. Proper concurrency control is the key. Shared memory vs message passing is incidental and application specific.

definitely! Reminds me of the golang saying > Don't Communicate by Sharing Memory; Share Memory by Communicating https://www.php.cn/faq/1796714651.html https://www.php.cn/faq/1796714651.html

tombert 1y ago

Yeah, similarly, Joe Armstrong (RIP), co-creator of Erlang explained it to me like this: > In distributed systems there is no real shared state (imagine one machine in the USA another in Sweden) where is the shared state? In the middle of the Atlantic? — shared state breaks laws of physics. State changes are propagated at the speed of light — we always know how things were at a remote site not how they are now. What we know is what they last told us. If you make a software abstraction that ignores this fact you’ll be in trouble. He wrote this to me in 2014, and it has really informed how I think about these things.

throwawaymaths 1y ago
The thing is that go channels themselves are shared state (if the owner closes the channel and a client tries to write you're not gonna have a good time)! Erlang message boxes are not.
- deleted 1y ago
  [deleted]
- kbolino 1y ago
  You don't have to close a channel in Go and in many cases you actually shouldn't. Even if you choose to close a channel because it's useful to you, it's not necessarily shared state. In a lot of cases, closing a channel behaves just like a message in its queue.
- tombert 1y ago
  Strictly speaking they’re shared state, but the way you model your application around channels is generally to have independent little chunks of work and the channels are just a means of communicating. I know it’s not one-for-one with Erlang.
- Kubuxu 1y ago
  You can think of closing the channel as sending a message “there will be no further messages”, the panic on write is enforcement of that contract. Additionally the safe way to use closing of a channel is the writer closing it. If you have multiple writers, you have to either synchronise them, or don’t close the channel.
  - throwawaymaths 1y ago
    Sure but the fact that it is shared state is why you can't naively have a go channel that spans a cluster but Erlang's "actor" system works just fine over a network and the safety systems (nodedowns, monitors etc) are a simple layer on top.
aatd86 1y ago
Isn't entanglement in quantum physics the manifestation of shared state? tongue-in-cheek
- psychoslave 1y ago
  Maybe. Or maybe we observe the same point of information source from two points which happen to be distant in the 3-coordinates we are accustomized to deal with, but both close to this single point in some other.
  - aatd86 1y ago
    but that still means that there is shared state on the projection from the higher tensor space. orthogonality needs to be valid for all subspaces.

gpderetta 1y ago

> Don't Communicate by Sharing Memory; Share Memory by Communicating that's all well and good until you realize you are reimplementing a slow, buggy version of MESI in software. Proper concurrency control is the key. Shared memory vs message passing is incidental and application specific.