Type annotate everything. Don’t mix integers and doubles, be explicit. Most important of all, do not ever make a long chain of nested result building function calls with those stupid trailing untyped dangling {} closures, especially when the closure expects an implicit return of an opaque ‘some’ type.

What I’m saying is, don’t use SwiftUI. It’s a pee filled kiddie pool to attract JavaScript react devs with awful performance and semantics.

It’s actually 28% I just checked but it’s front and centre there if you scroll down.

And nobody’s mad.

I do agree that the language design has gone overboard in the last couple of years, expecially in the various approaches to parallelism.

However they are not alone, just look at any programming language sponsored by companies, you need features to justify team sizes and naturally old features don't go away.

(And while the past shouldn't necessarily be a shackle on the future, it is striking that such a radically different set of trade-offs was picked for Swift vs Obj-C.)

I think both Go and C# are pretty nice languages, to give you an idea of where I'm coming from. And Rust is very interesting -- as a user you see software that gets written in it exceed the previous state-of-the-art (e.g., ripgrep).

I don't see that w/ Swift. It seems like the opposite. E.g., the terrible Settings rewrite that rolled out a couple releases ago...

Confession, though, while I did a lot of ojbc back in the day, I've never done more than kick the tires on Swift, so I'm not critiquing from a position of deep knowledge -- more like talking shit from the sidelines. But I do think I'm right. ;-)

Just compare C# 14 with C# 1, laundry list of features, and BCL changes.

Go, has plenty of warts caused by ignoring the history of programming languages.

Rust async/await story isn't that great, as it is kind of half done.

We could also add others to the list, each year get a few more constructs, runtime changes, standard library changes, whatever is the package manager of the year, and so on.

All have issues, then again we can go back to the famous Bjarne Stroustoup quote

"There are only two kinds of languages: the ones people complain about and the ones nobody uses".

In practice obj-c apps were snappy, e.g., good perf on extremely limited hardware of original iPhone. SwiftUI (I assume) of MacOS settings app much slower than the old version it replaced -- too much heavy programmer framework magic resulting in slower final code? That's my diagnosis/guess from afar (I might be wrong ofc), a pitfall that objc did not tend to lead developers into.