As someone who started doing SwiftUI recently, it absolutely boggles my mind that (1) this is even a thing and (2) Apple seem ok to treat it as an unsolvable problem.
When you finally solve it is some stupid wrong type passed in somewhere.
I agree with the other poster. This is so pathetic it makes me question the competence of the engineers working on Swift.
Smells like “we made a poor architectural / design choice and ain’t walking it back”.
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.
So then, another language which has lots of features, but if you are foolish enough to combine feature A, feature B and feature C, bad things will happen? C++ sends its regards...
Well apple themselves are pushing swiftUI and I suspect it will be the main (and only) approach as time goes on, even though its just a wrapper around "older" approach...
Not pulling the "citation needed" thing at all, genuinely curious (from anyone who might know), is that 1/3 number accurate? Is there data published on it anywhere? That feels like monumental news :-D
There are plenty of contradicting data, like the job market for Flutter being close to nil, if it was any relevant 30% of the App Store you would throw a rock and hit five Flutter developers.
Swift is an early example of Apple losing its way. Such a stark contrast to Objective-c -- which was a simple, fast compiling language that hit way above its weight for expressivity and runtime speed. A great language for its day. Swift is "a C++ hacker's first attempt at language design".
I would be fine with a Objective-C 3.0, but the big question would be how to fix the underlying C flaws, which was one of Swift's original goals.
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.
Taste & trade-offs aside, you've gotta make it compile reasonably fast! I do get that Objective-C is not the pinacle of language development, but you shouldn't give your main language the rough edges of a research project.
(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. ;-)
C# is starting to get a C++ like feeling, I no longer can keep track of all features that get added every year, especially when not able to work in vLatest in consulting gigs.
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".
Light-weight wrapper over C, so as fast as C when you want it to be. Message passing isn't as fast as, say, vtables, but is still quite snappy and flexible for loosely binding objects together. No generics avoids code bloat.
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.
Smells like “we made a poor architectural / design choice and ain’t walking it back”.