Comment by 90s_dev
6 days ago
How actually is Swift as a Rust alternative? Is it feasible?
The only gripe I remember with it is that all its APIs are weird.
Like instead of normal names, you have Apple-legacy-names for methods/classes.
6 days ago
How actually is Swift as a Rust alternative? Is it feasible?
The only gripe I remember with it is that all its APIs are weird.
Like instead of normal names, you have Apple-legacy-names for methods/classes.
Swift isn't quite as fast, because reference counting is inherently slower at runtime than the allocations/deallocations generated by the Rust borrow checker.
On the other hand, Swift has (IMO) a much cleaner and less symbol-heavy syntax than Rust. Easier to read and write. Less of a culture of doing crazy metaprogramming/DSL definition with macros, and the builder DSL built into the language (which SwiftUI uses) is pretty nice and generates mostly understandable compile errors.
I actually like Apple's APIs, even the legacy ones. There's some weirdness, like how some file APIs want paths and some want URIs, but it's not that bad.
Rust and Swift have done a fair bit of borrowing from each other "pun intended".
I've never got the chance to work with swift since their cross platform compatibility and "server-side swift" have been recent introductions.
In terms comparison, it really is the closest you can get to a rust that ARC BOX's everything (which has/ is planned to come down when lifetimes come in). You get a good runtime and good performance.
I can't speak to performance since I don't really race languages. But as far as feel and what not, it is very similar. But there is also a pretty good overlap in people who worked on Rust and people who worked in Swift. Graydon worked on both. So Swift has a lot of similarities with Rust. The way I usually word it is, Swift is like having C# with mostly everything you like about Rust.
I believe a lot of the legacy names come from when your interfacing with platform APIs like UIKit and such if you have to and they haven't quiet gotten a bump from their Objective-C APIs to have more swifty-APIs.
Depends on what you're doing. If you want to write systems code, Swift is very allocation-happy and will probably not be the best fit. They're trying to make an embedded Swift, but progress is pretty slow, since that's not going to be something that gets anyone promoted.
If you just want to write A Thing, then it's up to your individual taste, what's available in the ecosystem, etc.
Apple has started using Swift for production embedded code run within the Secure Enclave. I've been looking out for any evidence whether they are using it in the C1 modem baseband.
I don't think I'd push for it over Rust for those applications, but there is apparently wood behind the arrow internally.
They are different language designs sharing quite a few of the same features/philosophies.
Swift is good for business logic, like writing an app.
Rust is better for infrastructure, like writing a HTTP/3 server or Javascript VM.
Swift has an extremely good story about ABI stability, which makes sense when Apple ships a swift runtime and libraries as part of the OS, and needs the binaries to work across two dozen different major/minor releases.
Rust has up-front memory control primitives and options to remove the core library to cater to things like embedded systems development.
People have written apps in Rust, and Apple has written API backends and even device firmwares in Swift. I would argue both push against the ergonomics of the respective languages.
much of the new swift libraries/apis don't have the legacy "NS" prefixes you're thinking of