Re:Ask HN: Rust or Swift for system programming?
by millstone on Tuesday July 05, 2016 @01:16AM
(#12034519)
When I hear sharing I think of shared ownership, and Rust steers you strongly away from that. See for example the awkwardness of global or thread-local variables in Rust.
If you are referring to borrowing, Swift's answer is not class types, but inout. inout is not as flexible as Rust references, but it does not use reference counting. In most places where a Rust function would return a mutable reference, the analogous Swift function would take a closure that accepts that something as an inout.
Re:Ask HN: Rust or Swift for system programming?
by Manishearth on Tuesday July 05, 2016 @03:55AM
(#12034985)
Right, I refer to the concept of sharing data without necessarily involving shared ownership.
I am aware of inout, but like you said it's not as flexible. I find myself reaching for class types in Swift a lot more than in Rust.
inout works for sharing that is extremely local, but more complicated sharing in larger codebases is hard.
Sharing is something that is pretty necessary in programming; you are severely limited in what you can do without sharing. Trait objects are not, and are pretty rare in Rust. I often see people using enums over trait objects, and only sticking to trait objects for creating extensible APIs.
Rust provides a way of sharing that does not involve any extra runtime overhead, which gets used often. Swift does have nice optimizations to value-typeify things, but without a finer-grained distinction between the kind of sharing you want to do to hint the compiler, this will be vastly limited as compared to Rust giving an explicit choice between borrows and Rc.