Preventing deadlock wasn’t a goal of concurrency. Like all options - there are trade offs. You can still used gcd.
Yes they do. Just imagine seeing the following in a single file/function: Sendable, @unchecked Sendable, @Sendable, sending, and nonsending, @conccurent, async, @escaping, weak, Task, MainActor.
For comparison, Rust has 59 keywords in total. Swift has 203 (?!), Elixir has 15, Go has 25, Python has 38.
> You can still used gcd.
Not if you want to use anything of concurrency, because they're not made to work together.
Swift does indeed have a lot of keywords [1], but neither Task or MainActor are among them.
[1]: https://github.com/swiftlang/swift-syntax/blob/main/CodeGene...
It dilutes any point you were trying to make if you don’t actually delineate between what’s a keyword and a type.
Similarly, I find Combine / GCD code far easier to write and read and understand, and the semantics are better than structured concurrency. I have plenty of production Combine code in use by (hundreds of) millions of people and it hasn't needed to be touched in years.
And after all this "fucking approachable swift concurrency", at the end of the day, one still ends up with a program that can deadlock (because of resources waiting for each other) or exhaust available threads and deadlock.
Also, the overload of keywords and language syntax around this feature is mind blowing... and keywords change meaning depending on compiler flags so you can never know what a code snippet really does unless it's part of a project. None of the safeties promised by Swift 6 are worth the burnout that would come with trying to keep all this crap in one's mind.