Earlier quoted context omitted.
Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.
> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…
I hope to someday see the language at least do the opposite, have a specially-declarable "isolated" goroutine. In theory, the compiler ought to be able to analyze a goroutine, determine that it shares no data at startup with another process (i.e., nothing in a closure or something), determine that it only communicates via value-passing channels (which courtesy of my previous restriction, can be analyzed by simply looking at what channels are passed in at startup time, and some analysis of the types of the channels), and thus guarantee that at least this goroutine is fully isolated. Pervasive usage of the new keyword I'm hypothesizing would allow a diligent programmer to recover most of the isolation advantages without having to rewrite Go entirely. It also ought to enable some other optimizations against these guaranteed-isolated goroutines, the biggest of which is that they no longer need to participate in a global stop-the-world GC, both in that they can continue running while that is occurring and that they also relieve the global GC from the task of scanning over them.
(In fact all the analysis ought to itself be fully automateable, and the user shouldn't have to declare it; I'd want them to still have the option to make a declaration so the compiler can tell them if they screwed up, though. I don't like such critical functionality being behind an opaque optimizer.)
But this certainly won't happen soon; there's a large enough list of stuff that comes before that.