It’s a somewhat more pleasant Rust, with nicer syntax, where you get an additional option wherever you would have weird ownership semantics to just pay some extra cost to have the language solve it for you. Whether that is worth dealing with a worse toolchain is something for you to decide.
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.
> 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.
You can do the same in Rust of course, it just takes some boilerplate. Whether the Swift approach is genuinely "nicer" is probably a matter of personal opinion.
Niceness is an opinion but I don't think "you need more boilerplate so it is nicer" is one that many people share. When discussing aesthetics as one does here it's not very difficult to rank obvious choices like these.
