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

[Slava Pestov]

> On Aug 10, 2016, at 3:34 PM, Christopher Kornher <ckornher at me.com> wrote:
> 
> Would this prevent an object from being “known" to multiple threads? …multiple queues? If so, it would be overly restrictive for a general-purpose language. I assume that the plan includes a way to allow “unsafe” behavior to support other concurrency models.
> 

To be clear I'm not presenting any ideas for Swift here, just critiquing Go's model.

Yes, I'm just talking about 'safe' language features for passing immutable data between threads. This would not preclude other forms of concurrency from existing in the language, such as locks, atomics, etc. But I think if a user writes code with only message passing, the language should ensure that the result is free from data races. Go does not do that, which is unfortunate.

Slava

> 
>> On Aug 10, 2016, at 4:24 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> 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
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>