Async/await status?

What’s the current status with Async/await proposal? As far as I know basic building blocks around coroutines exist in swift already, but I guess there’s still lot of work before async/await works in Swift.

Is there something that could be worked on either in code or proposal to get this forward?

48 Likes

I don't understand why this has not been a high priority so far at Apple since Swift is mainly a language for developing client applications.

Probably because there have been items higher on the priority list for a while, ABI Stability being the main culprit. Don't worry, I'm sure they know that it's a highly wished feature.

11 Likes

I think Actors should probably be implemented before Async/Await.

Are there any other languages other than Erlang that have Actor like semantics for dealing with distributed systems?

I think it'd be extremely dubious to try and build actors into the language without async/await primitives already in place.

It's not just Erlang in this context, but any language targeting the OTP, or more specifically, the BEAM VM. So Elixir also follows the same models.

1 Like

The coroutines that Swift implements might not be the best for doing async/await things though. @John_McCall did an excellent talk about coroutines for the 2018 LLVM conference if anyone is curious about them.

5 Likes
  • unidirectional async message sends are great, but inconvenient for some things. We want a model that allows messages to return a value (even if we encourage them not to), which requires a way to wait for that value. This is the point of adding async/await.

"inconvenient" maybe. The BEAM VM (Erlang related?) languages don't have Async/Await from what I can tell.

async/await is just not interesting to me if we don't get actors. Swift would just be playing catch up with C# and JS. Actors is a requirement for better fault tolerance specially on the server. From what I can tell async/await can be added anytime and I don't see why it would have to be a hard requirement for actors. Of course please correct me with evidence if I am wrong.

1 Like

I think it's a safer bet that Swift is used far more for applications than servers, and async/await is much more useful than actors for application (UI) programming. Actors may be more important to you, but I think it's a hard sell that they're more important to Swift developers as a whole.

5 Likes

Rather than phrase it as an either/or, I think it's good to realize that async/await and actors are complementary features that address different problems:

  • async provides lightweight execution contexts, allowing for more expressive heavily concurrent code.
  • Actors provide lightweight resource contexts, allowing different parts of a program to be isolated from each other so they can fail independently and be more easily reasoned about.

There are definitely synergies, but progress can be made on either independently.

34 Likes

There's no fixed timeline, sorry. If you or anyone else want to continue one of the existing design threads on this topic, or look into the implementation work, you're welcome to.

7 Likes

Are there any other languages other than Erlang that have Actor like semantics for dealing with distributed systems?

Flow

(Basis of FoundationDB)

https://apple.github.io/foundationdb/flow.html

1 Like

I think that with the introduction of "Combine" by Apple, the async/await proposal needs to be adapted to the new reality.

I could imagine that instead of being low-level, async/await moves a bit up and allows to await on Publishers:

// with a Service like this:
protocol MyService {
  func retrieveOne() -> Future<String, Error>
}

// you might then call it like this:
func invokeService() async {
  do {
    let s = await myService.retrieveOne()
    // do something with s ...
  }
  catch {
    // do something in case of failure ...
  }
}

func handleButton() {
  beginAsync(scheduler: DispatchQueue.main) {
    await invokeService()
  }
}

When the async-context is created with a scheduler, an await might implicitly call receive(on:).

For Publishers other than Future, a for s in await myService.retrieveAll() ... syntax might be introduced.

The question might be why to bother with async/await when we could use the fluent style of reactive functional programming.

I think that the reactive style is best to be used when you have a publisher/subscriber relationship which lasts longer (think MVVM) than a single request/response - in which case the async/await style should be preferred instead.

For that to happen Combine needs to be open sourced otherwise it would only be an apple platform specific swift feature which we don‘t want. ;)

Not necessarily: there could be an Awaitable (and MultiAwaitable) protocol which could be adopted by Combine and other frameworks.

But yes, would love to see Combine be part of the Swift OpenSource project - especially as it is somehow sitting between Stdlib and Foundation.

Such a protocol would lock down this feature to even a future swift version than Combine was introduced.

I don‘t have any other solutions to offer here, I‘m more interested in the core team finalizing and publishing co-routines that the stdlib itself is already using.

1 Like