TAtayistay·Oct 29, 2024
If you have a recent machine, the actual developer experience isn't too bad. It's just not a language for language purists (was it ever?).
I'm enough of a purist to be annoyed whenever I see the "expression took too long to type check" error. (I think bidirectional type inference isn't worth it with Swift)
The gaggle of verbose pointer types makes me want to switch to C++ whenever I have to deal with memory directly.
As the article mentions, a bunch of features were added for the sake of SwiftUI. Function builders allow SwiftUI's syntax to be minimal. They allow you to write:
VStack {
SomeView()
AnotherView()
}
instead of something like
VStack(
SomeView(),
AnotherView()
)
Given the rather bad (still!) error messages you get with SwiftUI that seem to be a result of function builders, I'd say it wasn't worth it
Read the rest
. At least I get fewer of the "couldn't produce a diagnostic, please file a bug" errors than I used to.
Then there are property wrappers, which wrap struct/class fields with get/set code (IIRC Lattner didn't like the property wrappers). They've been partially replaced in SwiftUI by macros. The @Observable macro (probably the most widely used one) decorates your class with code that notifies listeners (almost always SwiftUI) of changes. I'd be curious to see what SwiftUI would look like without property wrappers (or macros).
I think they had a missed opportunity to really add robust updating of views in response state changes. Currently it's still relatively easy to not have your SwiftUI views update because your data model uses some object that isn't @Observable.
I wrote a UI library inspired by SwiftUI, but in Rust [1], and of course I couldn't add anything to the language, and more experienced Rust programmers discouraged me from using macros. So it can be done without all the extra stuff Swift added.
[1] https://github.com/audulus/rui