Ok, didn't know that, can you point to some pages that explain how you can reference the same memory from two threads in the same process with these languages?
Here's a snippet of Go code, with comments, which spins up different goroutines (lightweight thread primitives) to read and write values in a shared map: https://gobyexample.com/mutexes
Can goroutines run on separate cores? Because I'm pretty sure go explicitly decided to not share memory between threads because google thinks async. is too hard to understand for programmers...
You probably mean channels - yes they let you avoid dealing with synchronization of shared memory access explicitly, but they still use mutexes underneath, so you can use those directly if you want (instead of/along with channels).
Yes, goroutines run on separate cores. Go uses an M:N threading model. goroutines (M) which are ready to run are scheduled on a thread pool of POSIX threads (N) which I believe is sized to match the number of cores in the processor. Nothing stops those goroutines from racing on shared memory. However, there is a convention that before accessing some shared memory, goroutines synchronize themselves using channels. ("Do not communicate by sharing memory; instead, share memory by communicating.")
Are you sure? I thought nim could use shared memory semantics if you wanted to? My understanding was it (cleverly) makes a subset of the language for concurrent work that requires you to be explicit about that activity.
JavaScript doesn't have threads so the point is moot.
Only Erlang doesn't share memory between processes.