This is my feeling as well. It feels to me that based on the current product, Swift had two different designers: one designer who felt swift needed to be a replacement for Objective C and therefore needed to feel like a spiritual successor to that language, which meant it had to be fundamentally OOP, imperative, and familiar to iOS devs; and another designer who wanted it to be a modern functional, concurrent language for writing dynamic user interfaces with an advanced type checker, static analysis, and reactive updates for dynamic variables.

The end result is a language that brings the worst of both worlds while not really bringing the benefits. An example I will give is SwiftUI, which I absolutely hate. You'd think this thing would be polished, because it's built by Apple for use on Apple devices, so they've designed the full stack from editor to language to OS to hardware. Yet when writing SwiftUI code, it's very common for the compiler to keel over and complain it can't infer the types of the system, and components which are ostensibly "reactive" are plagued by stale data issues.

Seeing that Chris Lattner has moved on from Swift to work on his own language, I'm left to wonder how much of this situation will actually improve. My feeling on Swift at this point is it's not clear what it's supposed to be. It's the language for the Apple ecosystem, but they also want it to be a general purpose thing as well. My feeling is it's never not going to be explicitly tied to and limited by Apple, so it's never really going to take off as a general purpose programming language even if they eventually solve the design challenges.

▲

steve1977 15 hours ago | parent | next [-]

The thing I often ask or mention in discussions about SwiftUI is, if SwiftUI is so good and easy to use and made for cross-platform, why did take Apple themselves for example so long to port their Journal app to macOS? This is a trivial application, something you'd have found in a beginner programming book as an example project 10 or 20 years ago.

I get all the points about Swift and SwiftUI in theory, I just don't see the results in practice. Also or especially with Apple's first party applications.

▲

astrange 12 hours ago | parent [-]

Journal has a lot of extra features where it autogenerates suggestions based on what you've done lately.

	▲	steve1977 3 hours ago \| parent [-]
		Most of these extra features are still pretty trivial. What does it do? Suggest entries based on recent walks, music you listened and photos. Nothing that would justify a multi-year porting effort IMHO. And these features don't even work across devices, or rather, from what I can tell, they don't exist at all yet in the macOS Tahoe version. Similar things could be said about for example the Passwords app. It works, it's functional, sure. But compared to apps like 1Password it's really, really barebones. You can't even change the way the it generates passwords if you need to comply with a specific policy for example.

▲

cosmic_cheese 14 hours ago | parent | prev [-]

It's an unpopular opinion, but my belief is that trying to go all-in on one paradigm is the actual mistake. There's several types of awkwardness that arise when a UI library is strictly declarative, for example.

On Apple platforms, I've had a lot of success in a hybrid model where the "bones" of the app are imperative AppKit/UIKit and declarative SwiftUI is used where it's a good fit, which gives you the benefits of both wherever they're needed and as well as an escape hatch for otherwise unavoidable contortions. Swift's nature as something of a hodgepodge enables this.