[worik]

> Swift 5.5 didn’t get all the way towards rust-style data race

When I experimented with it it was trivial for one thread to interfere with another. So Swift got nowhere towards data race safety. Still stuck in the 1990s

I know not what you mean "Swift Concurrency". When I was doing it all we had was DispatchQueue which was an obfuscation of `fork`. Quite shameful really.

I think the main point is that Swift is a failure.

"although SC still has a ton of issues worth discussing" once I would have cared, but this year (decade, century) I am just very glad putting meat in my fridge no longer depends on those rouges from Apple who treated me so badly when I was sweating so hard making software for their platforms (not to mention paying them so much money). In 2024, for a company like Apple, for their flagship developer offering, why would anyone still have "a ton of issues" with it?

Apple is now an example of why popularity is a terrible metric to estimate quality of technical offerings. What a shame. How far the mighty have fallen

[ezfe]

Okay, so you're saying you don't know what Swift Concurrency is and they say Swift is a failure.

Swift has async/await built into the language with many compile time guarantees of thread safety.

[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.