I'm not the only one that feels like they were led along by the hype train of concurrency for over a year. Then had the OS feature sprung on us at the last minute.
async/await is a standard feature that can easily be put into the compiler.
I used to write such language syntax back in 2002, building custom scripting languages sitting on assembly ARM RISC for video games.
um, ok.
FYI, I'm not the one flagging.
I know.
My message is that, this is something which is in part a failure of communication by the Swift (Apple) team.
It shouldn't happen again. A lot of teams were waiting and planning for these features.
I mean, sure, but calling it overhyped rubbish disappointment won't get us anywhere. Really simple. They also said they're looking into back-porting it (not a guarantee), if you're interested.
(post deleted by author)
I don't want to encourage the frustration but the discussion here is a great representation about the severity of this issue.
For any mid-size+ company is totally not applicable to drop the iOS 14 support just for a feature we hoped to see at language level since...since what? probably since the first version of swift.
I'm really sad to see the effort the swift team put in this release to be "wasted" by this news.
I'm not good enough to evaluate the tech difficulties to make this feature usable in older runtime but I think this kind of language feature must be part of the language itself (we've awaited it for years while Kotlin is capable to use coroutines on phone older than 6years and C# allows it on mobile since Windows Phone 7.5).
Hope something may change in future especially because Swift worth something better than this 
This topic is temporarily closed for at least 4 hours due to a large number of community flags.
Unfortunately due to a high number of very aggressive code-of-conduct-violating posts on this thread that were correctly flagged by community members, the system auto-locked it for a cool-off period. It will reopen shortly. Thank you to the participants who submitted the flags. Generally it is much better to flag posts than to reply to obvious trolls, as once the mods approve the flags the offending posts are removed but the replies remain.
As a reminder – everyone here wants the best for Swift, and for Swift and Swift's new features to be adopted widely. There are no absolute right answers, both in policy and technical solutions. What's great about being an open source project is that we get to talk about those trade-offs here. But please assume good intent on all sides when engaging in the discussion.
This topic was automatically opened after 8 hours.
It keeps getting brought up here, but so far I haven't read an explanation from anyone from Apple, so let me try to ask directly - why is it that Kotlin coroutines don't have the same problem? Does that feature not require runtime support? Is there a writeup on this somewhere already that anybody can point to? I have close to zero experience with the Android ecosystem, so I'm probably not seeing the issue...
(in response to posts that have been correctly flagged as off-topic)
Once again... please don't post speculations about the "real" reason why back deployment isn't available. It's disrespectful to those engaging on the topic about the genuine technical challenges that need to be overcome.
I wonder if it would be possible to decouple structured concurrency and code transformations. The Objective-C interoperability proposal shows the duality between async functions and ones accepting completionHandler: (T) -> Void.
If the compiler can provide required code transformations and expose such duality allowing us to call the same function either via await or with a completion handler, then third-party libraries can be implemented to use the new syntax with other concurrency libraries.
Respectfully, further information about those technical challenges does not appear to be forthcoming.
Others and I have asked for details about which aspects might be particularly challenging, or when we can expect more information, but there don't seem to be any answers. Without those details, this topic can't be any more than a collection of people saying they can't adopt iOS15 yet. I'm not sure what the point of it is.
(Okay, Ted did briefly mention that there were some changes to Dispatch. Still, not very specific.)
Demanding that more in-depth answers to complex technical questions be provided in a quicker timeframe is really not something I think matches the adverb "respectfully".
Wow. No wonder people are upset.
Also, asking for more information is really not something I think matches the verb “demanding”.
I’m curious why supporting AppClips means you can’t support iOS 15. I’m looking at a project that will use AppClips and I’d love to learn what appears to be a gotcha from you rather than the hard way. I was considering supporting iOS 15 only just so I could engineer it with async/await from the ground floor.
Anyone interested in more info on why backporting will be difficult on Apple platforms should watch the WWDC video Swift concurrency: Behind the scenes. tl;dw: The new cooperative thread pool optimized for Swift concurrency doesn't exist on the older OSes. Without it, Swift can't make the reliability and performance guarantees it needs to.
If I understood it correctly, coroutines in Kotlin are a library feature on the most parts. The runtime here is the JVM which is not to be tampered with by Kotlin.
Here is a deep dive talk about Kotlin's Coroutines: KotlinConf 2017 - Deep Dive into Coroutines on JVM by Roman Elizarov - YouTube
(and here is an Introduction in case you want to learn the basics first: KotlinConf 2017 - Introduction to Coroutines by Roman Elizarov - YouTube )
regards,
Lars
I was just about to write exactly the same thing. This session goes a long way to explaining why this is such an issue. I very much admire the work that has been done here to make Swift's adoption of async/await not only a pleasure to use but also super performant (as long as the rules are followed).
I don't really know what the solution is here. I can see why things were done the way they were and the very valid reasons behind them, I would have done the same thing, but at the same time I waiting a number of years before using these features is very deflating.
I honestly think what the Swift and core teams have done here is great, and it shows by how many people want to jump in and get using this great new piece of technology. It's just a shame that we now have this shadow looming over it.
I guess the question to the swift team is; would async/await even work on the older versions of GCD, even from a non performant thread explosion type of approach? What kind of performance issues are we talking about if it is possible? And is it even a realistic thing to consider?
I'm probably oversimplifying here, but it would be good to start scratching the surface a little here, even if we don't go super deep into the topic.
This is incorrect. async/await as implemented in Swift requires runtime support, including new runtime entry points to manage tasks and actors, changes to core runtime functionality such as type metadata, and tie-ins with the OS kernel. Some of these are covered in the behind-the-scenes talk.
Despite any surface-level similarities, Kotlin's technology stack is completely different from Swift's. Comparison at a technical level is not likely to be meaningful, especially given that the technical challenges for back-deploying a Swift Concurrency are mostly understood.
The performance and semantic impact of doing this is hard to evaluate without having done all of the work to back-deploy. This is one of several "unknowns" that would require detailed evaluation. It could very well end up being the case that it is possible to back-deploy, but the experience of running on older OS's is poor.
There's some description of the technical issues above, as well as the aforementioned blog post on evolving in an ABI-stable world. This is not the first time that a new language feature has not been available on previous OS versions: opaque result types came in Swift 5.1 and are not available on Apple OS's prior to iOS 13 / macOS 10.15 Catalina, due to the same technical issues.
Frankly, I don't think any more technical details will change the discussion in any way. I could write many paragraphs about all of the issues we face, the approaches we think will work, and the unknowns still out there, but the best possible outcome from doing that is that I spend a whole lot of time writing it and the takeaway is "yep, that's a bunch of work, they weren't kidding." There is no silver bullet, no singular insight, that will suddenly make the work to backward-deploy become trivial.
It is completely reasonable for folks to ask about the limitations and to report on how the lack of backward deployment affects them. As Ted said, those of us at Apple hear you, and we appreciate the feedback. It's fine for that to be the entire point of this thread.
Doug
[EDIT: Another post came in, so I've added a paragraph about performance/correctness considerations]