Swift 5.5 unleashed with async keyword to fix 'pyramid of doom', plus other changes in 'massive release' Apple has emitted version 5.5 of the Swift programming language, described as a "massive release," including async/await keywords, package collections, and improved Objective-C interoperability. The most anticipated new features in Swift 5.5 are around concurrency. One of the issues with Swift's earlier approach to …
After working in a few programming languages and styles, I can confidently say that most asynchronous designs are antipatterns. There are few times when you call a method but don't need the answer until later. When most calls are synchronous by default, you're adding async wrappers 4% of the time. When they're async by default, you're adding unwrapping or chaining 96% of the time.
Every 'await' is essentially a manual yield back to the event loop, where the function stops running and other asynchronous code can be scheduled. It's basically co-operative threading and you are subject to the same kinds of concurrency bugs you would get in a regular multithreaded program with syncronous I/O. It would be better if the language simply provided green threads and made async I/O look like sync I/O, or just use threads.
The joy of async/await is that most calls are synchronous and you wrap the asynchronous ones.
And as noted above, this is sugar for storing the state, returning to the event loop, running more events, and then picking up when the next event happens.
Sure we did all that by hand in select(2) loops thirty years ago. It is a lot less fuss. And these days a lot more stuff comes from the network or from other threads. And it removes that boiler plate.
I disagree.
The use case for “async” is primarily to prevent blocking-waits within threads, not to pre-compute things. The classic example is networked APIs
HttpResultThing result = await fetchURL("http://test.com");
// --- thread yields here until resource is ready.
if (result.IsOk )
{
// do your processing
}
Any equivalent without async either busy-waits, or requires all of the plumbing hidden by “await” to be implemented explicitly in the application, usually creating ideal conditions for callback-hell (“the pyramid of doom”) in the process.
The advantage of having async in the language, and thus the runtime libraries, is that it lowers the cost of doing things the “Right Way”. File I/O, for instance, is a blocking operation, but most C/C++ devs tend to ignore this fact because a call to read() is usually a fast operation... until the files get big, or have to be accessed over a network. A framework where all I/O is asynchronously handled makes applications more responsive to events without needing more threads.
Your second point is also not correct - async is an optional feature: methods are never async by default, and if the Swift runtime is anything like the C# one I’m familiar with, most methods are not async, unless they can block your thread. For the case of Swift, scopes only gain the async plumbing silently if they include an “await” inside (as it makes no sense to use “await” in a non-async context); no “await”: no async.
The truth is, if you really care about performance, you write the bits that need that performance in C, where you have much tighter control over the resources at your disposal. If you’re using any high-level language that’s managing memory and tasks for you, you have already tacitly admitted that you do not require maximum performance for your application.
I think async / await keywords work really well when I've used them in Rust. The code is asynchronous but the code is clean and readable - call this thing and await for it to return. So the flow is basically synchronous but it yields and the scheduler / executor can be getting on with making progress on something else.
I'm sure the same is true for other languages that implement these keywords. It's way easier to write and to understand than promises (for example) where you'd be chaining actions onto the end of other actions and it becomes a huge mess.
> That code is lovely but the first "await"ed call will need to finish before the second starts.
What, really?
As a non-Swift developer I looked at that example and thought: cool, each await statement runs in parallel and the surrounding code automatically waits at the end of the enclosing block for all of them to finish.
As that is apparently not the case, I'm now asking myself why not, as that would be a lot more convenient?
The purpose of await is to write code that resembles synchronous code but each await is an opportunity for a scheduler to be making progress on other async tasks. So basically the scheduler will call each async task asking them to make progress in turn, and if they can't they yield and it goes onto the next one.
It is actually a fantastically powerful construct since it makes async code easy to read while allowing code to make better use of hardware. I use it in Rust and it's a vast improvement over earlier attempts at async using a promise style callback where it can it can very hairy, very fast.
But if the next one requires the output from the first one (we're writing code like it's synchhronous) then it can't start.
I think you're right, but the other tasks that are getting processor aren't in this thread, it's letting other threads get a bit of the pie. So it helps you scale and parallelise but doesn't magically run two of those awaited statements at once. They have to complete before the next one can start.
The big problem with the Swift 5.5 release on Apple platforms is that there is no support for the concurrency changes on OS versions before iOS 15 / Mac OS 12, which, despite the rapid upgrade of most Apple users, still leaves those real world developers whose apps support older OS versions out in the cold. It's fine for hobbyist developers, but in the real world forcing a latest OS minimum is tough - even if 90%+ of active devices will be using it within 6 months, that last few % tend to be *very* vocal.
There are some comments from internal Apple people on the Swift forums that work is ongoing to back port the changes but no certainty that it will work, or how far back it would offer support. A lot of major third party systems still support back as far as iOS 10.0, so it will be years before they move to a minimum of 15.0 and make this usable, in the meantime they are pushing forward with a Swift 6.0 which sounds like it might also need more OS support and thus be iOS 16 as a base.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
