> ... there's plenty of mainstream, accepted science that's plain, flat out, provably wrong
:
:
> I'd name some examples, but you wouldn't believe me.

I probably would not. You would probably be wrong

So long as you "await"

Not really concurrent

Async/await is not a solution to poor thread models.

Async/await is cooperative multitasking and is no help at all for cpu bound problems.

For i/o intensive systems it makes non-blocking i/o look like blocking i/o, and people find that helpful.

I do real-time i/o so I need more control and Async/await is unhelpful.

It is a worthy adition to Swift I agree. But they sorely lack Rust's excellent design in this area

I am unconvinced

I have used Swift (stopped about two years ago) and use Rust extensively these days.

People commenting here have mentioned the dreadful Xcode. But if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.

To be clear it's failures as an editor or build system are not the main problems with Xcode (albethey very frustrating when the intermittent problems show up) it is the abject failure of the tooling.

We never got the profiler to produce anything intelligible after days of trying, spread over several weeks.

SwiftUI is not part of the conversation here, and I limit the amount of UI building I do, but it shares all the problems of declarative UI frameworks - mainly "where is the code?". Debugging logic problems is nigh impossible in code you're unfamiliar with

The very worst part of Swift were the thread control. Trivial to overwrite shared memory, "DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications

Swift is probably better than Objective C, the latter being from the 1980s, and things have moved on, if your target is iOS and friends, and you are sure you never want to port, then obeying Apple is a wise business decision. Other than that stay away from it. Use Go for most things, and Rust when you must