[swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Slava Pestov]

> On Aug 10, 2016, at 3:22 PM, David Sweeris <davesweeris at mac.com> wrote:
> 
>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> As I understand it, a big weakness of Go's model is that it does not actually prevent data races. There's nothing preventing you from sharing pointers to mutable values between tasks, but I could be wrong about this.
> Is that bad? Sharing pointers seems like a cheap way to share data, and as long as you know what you’re doing, why should the language get in the way? Now, if said code really does have performance advantages over the “safer” methods, and it really is safe because for whatever reason the race condition can’t actually happen, the language (or library) ought to have a way to express that without having to write “unsafe” code. In the meantime, though, you’ve gotta ship something that runs and meets performance requirements.

Well, ideally, the type system would be able to enforce that values passed across thread boundaries are immutable. Rust's model allows this, I believe.

The possibility of mutating shared state in an unprincipled manner is "bad" in the same sense that being able to call free() in C is "bad" -- it's an abstraction violation if you get it wrong. Compared to languages with automatic memory management, there are advantages (control over memory management) and disadvantages (fewer static guarantees).


> 
> - Dave Sweeris