4 ms·

Which they then failed to follow, especially since goroutines share memory with each other.

bayindirh 11mo ago
Threads share the same memory by definition, though. When you isolate these threads from a memory PoV, they become processes. Moreover, threads are arguably useless without shared memory anyway. A thread is invoked to work on the same data structure with multiple "affectors". Coordination of these affectors is up to you. Atomics, locks, queues... The tools are many. In fact, processes are just threads which are isolated from each other, and this isolation is enforced by the processor.
- dontlaugh 11mo ago
  Goroutines aren't posix threads. They could've lacked shared memory by default, which could be enforced by a combination of the compiler and runtime like with Erlang.
bloppe 11mo ago
Who is "they"? This isn't Rust. It's still up to the developer to follow the advice. Anyway, I would stop short of saying "Go chose shared memory". They've always been clear that that's plan B.
- dontlaugh 11mo ago
  Go's creators said "Don't communicate by sharing memory", but then designed goroutines to do exactly that. It's quite hard to not share memory by accident, actually. It's not like it's a disaster, but it's certainly inconsistent.
  - bloppe 11mo ago
    I don't think allowing developers to use their discretion to share state is "certainly inconsistent". Not sure what your threshold is for "quite hard" but it seems pretty low to me.
    - dontlaugh 11mo ago
      Goroutines could've lacked shared memory by default, requiring you to explicitly pass in pointers to shared things. That would've significantly encouraged sharing memory by communicating. The opposite default encourages the opposite behaviour.
yvdriess 11mo ago
Go is a bit more of a low level language compared to actor languages where the language enforces that programming model. I think the point of the slogan is that you want to make the shared memory access an implementation detail of your larger system.

Threads share the same memory by definition, though. When you isolate these threads from a memory PoV, they become processes. Moreover, threads are arguably useless without shared memory anyway. A thread is invoked to work on the same data structure with multiple "affectors". Coordination of these affectors is up to you. Atomics, locks, queues... The tools are many. In fact, processes are just threads which are isolated from each other, and this isolation is enforced by the processor.

dontlaugh 11mo ago
Goroutines aren't posix threads. They could've lacked shared memory by default, which could be enforced by a combination of the compiler and runtime like with Erlang.

bloppe 11mo ago

Who is "they"? This isn't Rust. It's still up to the developer to follow the advice. Anyway, I would stop short of saying "Go chose shared memory". They've always been clear that that's plan B.

dontlaugh 11mo ago
Go's creators said "Don't communicate by sharing memory", but then designed goroutines to do exactly that. It's quite hard to not share memory by accident, actually. It's not like it's a disaster, but it's certainly inconsistent.
- bloppe 11mo ago
  I don't think allowing developers to use their discretion to share state is "certainly inconsistent". Not sure what your threshold is for "quite hard" but it seems pretty low to me.
  - dontlaugh 11mo ago
    Goroutines could've lacked shared memory by default, requiring you to explicitly pass in pointers to shared things. That would've significantly encouraged sharing memory by communicating. The opposite default encourages the opposite behaviour.

yvdriess 11mo ago

Go is a bit more of a low level language compared to actor languages where the language enforces that programming model. I think the point of the slogan is that you want to make the shared memory access an implementation detail of your larger system.