3 ms·

This is sort of true in theory, but in practice there's a major difference in that nearly all the libraries in Swift use a reference-counted (i.e. GC'd) shared-

This is sort of true in theory, but in practice there's a major difference in that nearly all the libraries in Swift use a reference-counted (i.e. GC'd) shared-everything model, while in Rust nearly all the libraries use ownership and borrowing. The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world. This is not a knock on Swift--it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C and Core Foundation being a guiding principle of the language.

zozbot234 2y ago
> The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world. Of course, but the borrow checker in Rust does a lot to smooth out that potential friction; and Swift will also include comparable facilities starting from Swift 6, which will finally achieve comprehensive safety including in concurrent code. > it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C There's a comparable focus in Rust of getting not-quite-seamless compatibility with the COM-like model of... well duh, COM. See Microsoft's efforts at getting low-level components rewritten in Rust into their OS's.