[worik]

> Okay, so you're saying you don't know what Swift Concurrency

I just looked it up. It is Swift's version of async/await. That is a different thing from threads. I know what that is, used it a lot, because using threads was such a nightmare in Swift.

> language with many compile time guarantees of thread safety

From two separate threads you can access the same memory. No trouble (apart from crashes memory corruption....) at all.

Async/await is always a bad idea, and without a garbage collector it is a nightmare (look at the mess Rust has gotten into). Whatever, async/await is no replacement for parallel programming with threads. It is a different beast.

[ninkendo]

> I just looked it up. It is Swift's version of async/await.

Since you “just looked it up”, maybe don’t make blind assertions about something you clearly don’t know very much about?

It’s a lot more than async/await. It is a way to offer compile time guarantees about thread safety (through Sendable, which is part of SC), it’s an actor model (allowing shared mutable state to be isolated, leveraging async/await for coordination so that callers can pause if the actor is currently servicing another message) and a bunch more stuff.

I explained all this in my post you replied to, maybe read the whole thing before making wrong claims about stuff you spent 1 minute looking up?

[cube2222]

> Whatever, async/await is no replacement for parallel programming with threads.

Is it not for the vast majority of use-cases?

Sure, you can use async/await without parallelism, via a single-threaded runtime to just get single-threaded concurrency, but with a multi-threaded worker-pool async/await-like tasks or fibers I think mostly cover the use-cases you'd have for parallelism?

You have to make sure that you e.g. don't starve other tasks via having no yield points in a task that does a lot of computation (if you're doing cooperative tasks which Swift is doing iirc), but that's not a big one, and can mostly be solved by the runtime too (e.g. Go had cooperative fibers for a long time, until they chose to introduce preemption).

[neonsunset]

Async/await may or may not be a replacement for highly concurrent and parallel programming, depending on what is the execution model of the async runtime.

If Swift's model is anything like .NET's lightweight Tasks + async/await or Rust's async/await Futures and Tasks as implemented by Tokio or async-std, then it is such replacement.

[manmal]

> Whatever, async/await is no replacement for parallel programming with threads. It is a different beast.

Have you missed Tasks and Task Groups as well? And Actors? For now, they are an abstraction over threads, and IMO a good one. It’s actors + structured concurrency, borrowing from Kotlin‘s Coroutines and sprinkling some Erlang on top. Additionally, in Swift there is AsyncSequence + AsyncStream, a (woefully incomplete) Kotlin Flow alternative.