Conversation

This Tweet was deleted by the Tweet author. Learn more
Daniel Micay
@DanielMicay
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.
1
2
Joe Groff
@jckarter
Replying to
@DanielMicay
and
@revskills
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
1
Daniel Micay
@DanielMicay
Replying to
@jckarter
and
@revskills
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.
3
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
@jckarter
and
@revskills
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
1
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
@jckarter
and
@revskills
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.
1
1