In my experience it has a solid 90+% of the semantic expressiveness - ADTs, advanced pattern matching, if statements and similar being expressions, traits (split into "protocols" and "extensions" in Swift), automatic reference counting, a well-defined ownership model (albeit not quite as strict as Rust's), constructs to prevent data races, etc. It lacks things like explicit control over lifetimes, and also defaults to copy-on-write rather than to move semantics - that isn't unsafe, but it does lead to beginners writing programs that compile fine but behave in a way that's surprising to them. It also doesn't expose threads directly (similar to Go only having goroutines), but the concurrency model is quite nice to use. The language is obviously opinionated about its async runtime (Grand Central Dispatch, which is also available on Windows and Linux) so you don't have to wrangle with that yourself though of course it loses the power and flexibility of bringing your own.
On the flip side, Swift provides a lot of syntactic sugar that makes it feel faster/smoother to engage with than Rust. For example, enum literals don't have to specify the enum's name wherever their type can be inferred by the compiler. So e.g. when you are pattern matching on an enum value, the match arm `MyEnum::Red => {}` in Rust would just be `case .Red:` in Swift. It isn't much on its own, but each tiny QoL thing like this adds up.
Swift’s syntax I think also makes it more approachable for people coming from other languages. Rust by contrast is rather intimidating looking for anybody without a background in C++.
Thanks for the feedback here -- this definitely make sense. Interested in the copy-on-write vs move semantics... I'm so used to it now that I almost prefer the harder/more manual control/checking that Rust provides, but I definitely see the ergonomics of going another way.
I find Rust a bit easier for me to read, quite preference-driven as I prefer snake_case to camelCase but that's a tiny thing.
And weirdly enough I think I actually prefer `MyEnum::Red => {}`, but maybe that's just stockholm syndrome.
While I do appreciate macros, and use them sparingly I find the best case for them is doing things like generating to/from <protocol> (e.g. JSON) implementations.
In Haskell, there's a fully baked system for derivation where you can set up implementations that walk the type trees, but most other languages don't have that -- I find macros to be a great slightly lower complexity way to do this kind of thing.
What is Swift's answer in production? Does everyone just write extensions for their types? Rust's serde is a joy to use and 99% of the time "just works", despite the macro magic.
> Type system function resolution
I'm not sure this is a real problem for me or most people, but taken with the point about polymorphism (I guess this point is basically about late binding), I see the benefit here.
> Protocols vs Traits as implemented
Generic methods being allowed in Swift is quite nice.
> Sugar
Great points in there -- some of them are style/preference but I can definitely see benefits to a bunch of them.
The string interpolation point you might want to update (Rust does that now!)
Named arguments are also quite amazing.
Again, fantastic list -- saved! I've been meaning to give Swift a proper try lately and this is a great reference.
For the record "No macros", is one of the things that is out-of-date. There is some discussion about it in the comments... maybe I'll be forced to actually update it :)
After having written a few of them at this point at $DAYJOB and on my own... They're actually not so bad at all -- it's quite nice the world that they open up.
I'd venture to say most people are mostly annoyed at the overuse of macros (where a simple function would do).
Rust's attribute system is something it REALLY got right -- stuff like #[cfg(test)] and the conditional compilation stuff is really really impressive. Not sure what cross platform dev looks like in Swift but the bar is quite high in Rust land.
