It is nice that Go is trying to learn from Pony and Midori. I wonder whether any Gophers have started to learn about object-capability theory and the reasoning

It is nice that Go is trying to learn from Pony and Midori. I wonder whether any Gophers have started to learn about object-capability theory and the reasoning behind why so many values are immutable in Pony, Midori, Monte, and other capability-safe languages. To expand on this a bit, in ocap theory there is a concept of "vat", an isolated memory space for objects which has its own concurrent actions isolated from all other vats. In a vat model, data races are nearly nonexistent; in order to race, one would have to choose a shared variable in a single vat, and then deliberately race on it. But this is not common because ocap theory enforces heavy object modularity, and so shared variables are uncommon. Additionally, a "deliberate race" is quite tricky. Vats prepare work with a FIFO queue. In the Monte language: # A flag. We must start it as `false` because Monte doesn't allow uninitialized names. var flag :Bool := false def setFlag(value :Bool) :Void: flag := value # Set the flag to `true` immediately. setFlag(true) # Set the flag to `false` on the next turn. def first := setFlag<-(false) # Set the flag to `true` on the next turn. def second := setFlag<-(true) # And finally, when those two actions are done, use the flag to make a choice. when (first, second) -> if (flag) { "the flag was true" } else { "the flag was false" } You might think that this is non-deterministic, but in fact the delayed actions will each execute in order, and so the flag will be set first to `false` and then to `true`.