Async/await status?

(Mox) #1

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?


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.

(David Hart) #3

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.

(Chéyo Jiménez) #4

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?

(Erik Little) #5

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
(Erik Little) #6

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.

(Chéyo Jiménez) #7
  • 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
(Adam Kemp) #8

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.

(Joe Groff) #9

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.

(Joe Groff) #11

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.

(Jacquis Lewis) #12

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


(Basis of FoundationDB)

1 Like