[tl]

I think for a lot of us, the addition of view builders and function builders that ignored the process of adding features to the language just so the SwiftUI team could use less punctutation was a jumping the shark moment for Swift. On top of that SwiftUI has been a disaster compared to Apple's existing UI toolkits because it's less featured than UIKit, less reliable and unlike UIKit, there's no new hardware forcing its adoption.

None of this is new per se; weird Apple specific edges like @UIApplicationMain and @NSManaged have always polluted the language. But, it's hard to buy in on "Swift world domination" when server-side Swift is stillborn, Rust is more appealing as a better bare metal language, Catalyst and SwiftUI are weaker than AppKit and UIKit, the last time Swift got a useful language feature was guard let in Swift 2.

[coldcode]

So far I've not found SwiftUI usable for my work at my (large well known) employer. I like some of the concepts, but it's insufficient to actually use for our apps. Instead my team built a component system on top of UIKit that gives us the benefits of easier to build UI, without the "holy" and incomplete design of SwiftUI. Having Swift has allowed this work to be easy to construct and extremely type safe, and gives us the benefits of being able to do more work with fewer people, which was sort of the goal of SwiftUI, but in a more compatible way.

[skohan]

I totally agree with your point about SwiftUI: that also was a moment where I started looking to other languages in terms of what I should invest my energy in for the next few years due to the problems in governance with the language.

On the point of "swift world domination", I still think this is largely a PR problem. I think Swift's identity as "compiled python" could make it a very good fit for many use cases where scripting languages are currently being used, due to it's clean, high level syntax and powerful type system. It still suffers a chicken-and-egg problem with respect to broader tooling and library support since it's viewed overwhelmingly as a language for making iOS apps.

[tl]

"Swift world domination" is from Chris Lattner, Swift's author. He proposed that Swift could simultaneously be better at text manipulation than Perl, data science than Python, high-performance compute than C, more expressive than Ruby, etc... The result is a language ideal for no one and pushed heavily by Apple.

Swift as a "compiled python" loses to Go, and that not even Go's design goal (though it is a fairly common use of it).

[skohan]

> The result is a language ideal for no one and pushed heavily by Apple.

Does it have to be "ideal" to be worthwhile? I think it fits a similar use-case to something like C# but it's a lot nicer to work with. I don't understand why Swift shouldn't be perfectly usable for data science, or writing server-less functions for example: it would be a perfectly suitable stand-in for Python or Go in these cases, but with a much nicer type system in my opinion thanks to the first-class optional handling.

> Swift as a "compiled python" loses to Go, and that not even Go's design goal (though it is a fairly common use of it).

I totally disagree. Go is a jail. It's optimized for big teams with a lot of turnover, where you want to prevent complexity in the code-base by choosing a language with very limited facilities for abstraction.

Swift on the other hand has a really flexible syntax, which allows you to hide a lot of complexity behind simple interfaces. In that way, it can be a lot more like Python, where the code you're writing is very much at the domain level, and you don't have to think about the implementation details very often. There are many things you can express in swift which are no expressible in go.

[yoz-y]

YMMV but I found SwiftUI pretty good for a framework that only has two years.

It runs circles around storyboards when it comes to collaboration and traceability. Disregarding bugginess, the previews are a lot better than what was possible with IBDesignables.

The integration with UIKit is actually quite well made, and for most part not needed.

> there's no new hardware forcing its adoption.

While there is no explicit new hardware, there are several popular features that are only doable using SwiftUI: home screen widgets and complications. It will also become the language in which to write universal iOS/macOS programs.

> when server-side Swift is stillborn, Rust is more appealing as a better bare metal language

I agree with this, at least from Apple's part most effort is clearly done on "application level" and usefulness of Swift outside there seems more exploratory at the moment. Personally I'd like them to start adding higher, rather than lower level functionality, and steer towards scripting.

[rvz]

> I agree with this, at least from Apple's part most effort is clearly done on "application level" and usefulness of Swift outside there seems more exploratory at the moment. Personally I'd like them to start adding higher, rather than lower level functionality, and steer towards scripting.

This here makes sense. I can see Swift becoming more focused on the application-level side at the moment and in the future becoming a way of writing cross-platform GUI apps in Swift, more likely if it is with Qt5 with direct C++ interop with a SwiftUI-like DSL.

As a Rust user, the server-side use-case for Rust is far more developed unlike Swift and would much rather see Rust pushing for low-level development as well.

However, I've seen many attempts for a cross-platform GUI library for Rust for a long time and it has been proven to be difficult in terms of adoption, implementation and maintenance. It would take an enormous amount of effort to cover all three of these difficulties from scratch and using bindgen bindings to wrap and maintain it and I'm afraid for them it would be more trouble than it is worth. But who knows?

I just don't see a mature cross-platform GUI library coming from the Rust ecosystem anytime soon.