Item — HN Reader

I’m sorry but reading your comment, you have not understood much about Swift (and GCD).

In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.

> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.

If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).

> We never got the profiler to produce anything intelligible after days of trying

You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.

> The very worst part of Swift were the thread control

Already talked about that one, but Swift has async/await now, also.

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 use async/await for my CPU bound problems and it works fine

So long as you "await"

Not really concurrent

Not very well known, but Swift has two builtin concurrency systems (in addition to the very well known async/await for parallelism): async let (not very flexible) and task groups (much more so).

You don’t have to await immediately!