Conversation

This Tweet was deleted by the Tweet author. Learn more

This also applies to Go but I didn't realize Swift also cut corners in this area. Java has data races but preserves memory safety in their presence. This sometimes means paying some additional performance costs to make sure it only goes quite wrong instead of horribly wrong.

Replying to

and

Not so much "cutting corners" as making tradeoffs. Swift wanted to have a zero-overhead FFI, and it's hard to see how to provide Java level guarantees without a full GC environment and expensive FFI

Replying to

and

As long as the library is thread safe, the FFI can still be zero overhead. The wrapper would only need to enforce thread safety if the library didn't already provide safe APIs. It would also be possible to have a concept of types that cannot be shared or sent between threads.

Replying to

and

Rust handles this without a performance cost. The vast majority of types like vectors, hash tables, etc. can be sent between threads (Send trait) and don't need to provide thread safety. Rc<T> is the main exception, with Arc<T> used when atomic reference counting is truly wanted.

Replying to

and

Yep. Swift doesn't (yet, maybe) have the unique ownership model to make that work

Replying to

and

I think Send and Sync can work without ownership. Ownership allows Rust to support sending nearly every type between threads without a deep copy. However, this can be supported without it, by having a way to steal the contents and uses of the original one will fail dynamically.

Replying to

and

In a language like Swift, far more types would just not be Send and those types would need to explicitly support stealing to support it without a copy. For example, a vector without synchronization can support stealing it to another thread by setting the existing one to 0 length.

2:29 AM · Aug 14, 2019Twitter Web App

Replying to

and

Swift has value types so those are all be Send, and supporting ownership more would really just mean extending what can be done with value types to include heap allocated data where a shallow copy prevents using the source (move). More flexible borrows would be a separate thing.

Replying to

and

Yeah, that's the kind of system we're building toward. If you run things in well-isolated contexts with explicit communication and you're mostly working with value types, races shouldn't be able to happen for the most part. It's less well behaved libs that introduce hazards