[worik]

> > First off, Swift has both memory & data race safety (as of v6) > But v6 is not released yet, right

As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted

I am well clear of the Apple development world now (thank goodness) but the tools were of very poor quality, albeit very nice looking, as of this time last year

For the sake of my friends still in the world I hope Swift 6 is better, but I fear the dumpster fire that is Xcode is too far gone to rescue.

The comparison with Rust demonstrates the utility of "design by committee ". Rust is far from perfect, but feels like the future where Swift feels like warmed up Objective C

[ninkendo]

> As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted

Swift Concurrency is the replacement for Dispatch and has been around since Swift 5.5 in (IIRC) 2021. It’s a completely different system, uses lightweight tasks (a la tokio in rust, or goroutines in go, etc), has a concept of “Sendable” for thread-safety a la rust’s Send, async/await, and a native `actor` type, among other things.

Swift 5.5 didn’t get all the way towards rust-style data race safety due to a few things they had to make warnings instead of errors (to avoid breaking existing code), and introducing keywords like `@preconcurrency` when importing frameworks that predate Swift Concurrency, to facilitate incremental adoption. They’ve also been adding more checks in each minor release to tighten things up.

IIUC Swift 6 is mainly going to turn all the warnings into proper errors and tweak some defaults so that you get proper data race protection on a default compile.

Point is, it’s totally inaccurate to say that Dispatch Queues is all that exists in Swift 5. You’ve had much better stuff for a while now (although SC still has a ton of issues worth discussing.)

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

[wahnfrieden]

Xcode 16 rewrote much of the autocomplete behaviors and the new engine is blazing fast in terms of UI blockage compared with 15, and stable. Everything to do with tagging etc not just completion itself.

[kaladin_1]

I don't know if this is irony or you've been in Apple ecosystem way too long.

I had to do a very simple macOS app for my personal consumption recently and XCode dx is nothing to write home about. The only reason I finished the project there was that I couldn't set up vs code quickly for Swift/Cocoa project. I had to endure the slow compilation time, slow reaction time of the IDE UI. You make a change you keep seeing squiggly lines for a while, it's as though the UI is booting up each time. It was a horrible experience coming from IntelliJ and VS Code daily experience.

Computer is 32Gb Apple M1 Pro. Imagine what will happen on some 8Gb i5 macbook.

[wahnfrieden]

Xcode 16?

[worik]

Can you get the profiler to do anything useful? Even comprehensible?

We tried and tried but there was nothing we could use amongst the blinking lights and wonderful graphics.

[wahnfrieden]

Yes