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.

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

Replying to

and

It does support shared state between threads for anything satisfying Sync, with the main non-Sync exceptions being Cell<T> and RefCell<T>. Mutex<T> is pretty much just RefCell<T> with the synchronization needed to satisfy Sync. I don't see a blocker for other languages to do it.

Replying to

and

It wouldn't be as nice in other languages because types would need to support stealing for sending unsynchronized mutable data without deep copies due to lack of built-in support for ownership and move semantics. Also missing &mut / &mut [T] for non-overlapping bounded tasks.

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.

Show replies