7 ms·

How Actors Work Internally in Swift

123 points by andrekandre 5y ago

msdrigg 5y ago
> The protocol states that all actors must also be Sendable, which is another new important piece of the concurrency proposal. This protocol has no actual code, and its purpose is to "mark" which types are safe to use in a concurrent environment. It looks like Swift is taking pointers from Rust. Specifically Rust's send/sync traits. There's even other keywords like unsafe in Swifts new `UnsafeSendable` for Sendable types that bypass compile time checks.
- correct_horse 5y ago
  Unsurprising, since the creator of rust, Graydon Hoare now works for apple on swift[0] in "a non-leadership position". [0] https://old.reddit.com/r/rust/comments/7qels2/i_wonder_why_graydon_hoare_the_author_of_rust/ https://old.reddit.com/r/rust/comments/7qels2/i_wonder_why_g...
  - fay59 5y ago
    I believe that Graydon left Apple a while ago, but following compiler Twitter, it’s pretty clear that the rust folks and Swift folks are usually in good terms.
    - monocasa 5y ago
      You don't by chance know a list of handles to follow to get started following "compiler Twitter"?
      - fay59 5y ago
        I would recommend @johnregehr, @shafikyaghmour and @trav_downs if you're new to the area. If you're particularly interested in rust, @myrrlyn, @ManishEarth and @steveklabnik are great follows. @jfbastien is a compiler dad-joker extraordinaire and @jckarter is a master shitposter (with a side of old Macs) if you're in need of compiler-oriented comic relief. In particular, John tends to get involved in a lot of interesting conversations, so he's great to find more people to follow.
    - jamil7 5y ago
      I believe a few apple employees also contribute to Rust right? Seems to be quite a bit of crossover.
- codetrotter 5y ago
  Swift and Rust have a very similar feel to them, and I love both of them. There is no doubt that there is a lot of cross pollination between the two. And at least one person that was involved in creating Rust now works on developing the Swift language.
  - jamil7 5y ago
    Can you comment on compile time for both in your experience? Larger Swift and SwiftUI projects are bring my (new) mac to a grinding halt and I’m finding myself working around things I know will be difficult for the compiler.
    - terhechte 5y ago
      I'm using both a lot. Rust has better compile times than Swift. It is especially not prone to these "one expression takes 60 seconds" scenarios. Although I feel that things have improved considerably with Xcode 13 beta. On the Rust side, there's an (almost-done) alternative compiler backend called Cranelift that brings 30-50% faster compile times for debug builds. This improves the iteration time considerably. https://news.ycombinator.com/item?id=25130528 https://news.ycombinator.com/item?id=25130528
- pjmlp 5y ago
  The concept of unsafe keywords in systems programming languages goes back all the way to 1960. Rust might have brought many interesting concepts into mainstream, however unsafe wasn't one of them.
  - monocasa 5y ago
    That combined with marking types as Sendable points strongly at Rust influence. Then when you know that literal Graydon Hoare is working at Apple on Swift, the Rust influence is undeniable.
    - trevor-e 5y ago
      The Unsafe API has existed since Swift 1 which predates Graydon joining, and `UnsafeSendable` is just following the language naming conventions.
      - monocasa 5y ago
        Perhaps this is exposing a gap in my knowledge of programming language history, but I'm not aware of other languages that mark types as threadsafe with an otherwise empty Send(able) implementation.
        pjmlp 5y ago
        See Concurrent Haskell as possible set of ideas how typeclasses can be used to constrain the set of operations and sequences a type can perform.
        monocasa 5y ago
        But that's pretty different, since normal code in that context uses immutable data structures and the channels, etc. are language features. You then don't have to tack something like Send(able) onto arbitrary types because they're immutable anyway. The whole point of Send(able) is thread safety in the face of generally mutable state in contrast to something like Concurrent Haskell.
- saagarjha 5y ago
  > There's even other keywords like unsafe in Swifts new `UnsafeSendable` for Sendable types that bypass compile time checks. Swift has used the “Unsafe” prefix for a very long time to indicate things that break its safety model, see for example the UnsafePointer APIs.
- layer8 5y ago
  Using empty interfaces (protocols) as markers is a longstanding practice in Java [0], although nowadays it is considered an antipattern and annotations are preferred. [0] https://en.wikipedia.org/wiki/Marker_interface_pattern https://en.wikipedia.org/wiki/Marker_interface_pattern
- tomovo 5y ago
  > taking pointers from Rust Surely you meant borrowing.
correct_horse 5y ago
I'm not sure if the author of this blog visits hacker news to read this, but your code blocks are unreadable without javascript. They're black highlighted black text.
- bnchrch 5y ago
  If you remove the wheels from a car don’t expect a smooth ride.
  - deleted 5y ago
    [deleted]
  - wott 5y ago
    Very unsuitable analogy. If you remove syntax colouring from a text, you do expect to still be able to read the text. Why the difference? Because the wheel is an essential component of a car, while syntax colouring is more akin to the paint job of the car: you change change it, remove it, it won't affect the function of the car. BTW, if we remove the CSS, the text becomes apparent again. So if we keep going with the same analogy, it becomes even more unsuitable: removing half of the wheels prevents the car from working, but removing all of them now restores a smooth ride. We quickly see how it turns absurd and contradicts.
- nyanpasu64 5y ago
  The site loads smoothly even with JS on. If you want to fix the code blocks with JS off, try the following: pre { background-color: rgb(40, 40, 35); color: rgb(248, 248, 242); }
kjaleshire 5y ago
Swift actors seem to differentiate from other actor implementations (see Erlang) which have a decoupled message queue. Calling into a Swift actor may be non-blocking, but the result must still be await'd and from the actor's perspective all calls are sequential and synchronous. By this token, actors seem to be the language-level implementation of a class where all methods are asynchronous, and also being protected by the same lock. The novel feature seems to be cooperative scheduling amongst actors.
- jnwatson 5y ago
  They seem to have done a great job of combining async with multithreading by using the actor pattern which is really smart. They also seem to have an m-to-n scheduler (not sure if in user space or kernel), so you can have more actors than “threads”.
  - bsaul 5y ago
    After having tried to follow the discussions on swift forums on concurrency and actors, i still couldn't make my mind on whether their design was "fancy" smart (aka : something subtle and brilliant, that few developpers will get their grasp on and lead to inscrutable concurrency bugs), or "stupid" smart (aka : take a complex problem and make it look simple). Actors in systems like erlang seem to make concurrency simple, and the model seems to be easy to grasp. On the contrary, a few code samples i've seen on swift forums made my mind twist trying to understand how the code was going to be executed..
    - dwaite 5y ago
      The big difference AFAIK with Erlang (other than reference types) is that Swift's model is reentrant, while Erlang's is not. This is why `await` is such an important keywords to litter around your code - anything can happen in between when you await and when you come back, including actor message processing. You could have another invocation against your actor instance happen in tandem. This definitely increases the learning curve, but likely still saves time later when you are fighting various deadlock conditions.
galaxyLogic 5y ago
"Actors is a feature that is part of Swift's Structured Concurrency, bringing a brand new format to write and deal with asynchronous cod" , Brand new? I thought Carl Hewitt invented Actors https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model
- ramchip 5y ago
  The next sentence immediately says: > Although what Swift brings is new to the language, it's not new to tech itself. I think it's pretty clear that the author meant "brand new to Swift"?
  - galaxyLogic 5y ago
    What I would have liked to have read is how their Swift Actors relate to or differ from the other existing models.
b3morales 5y ago
It seems to me there's some real cognitive dissonance in the fact that Swift is promoted as a systems programming language, but its facilities are insufficient to implement its own runtime. I like the language well enough, but there's a lot of "almost-but-not-quite" frustrations about it in that domain. Bit of a tangent, I suppose, but I was disappointed to see that the actor implementation continues enlarging the C++ core of the language. I also think that combines with the fact that the project is, in reality, controlled by Apple and not truly open, to create an extraordinarily high bar for contribution. I think the very narrow needle it's trying to thread between its base case as a GUI applications environment and other types of programs may end up dooming it. You can't please all the people all the time...

123 points by andrekandre 5y ago

> The protocol states that all actors must also be Sendable, which is another new important piece of the concurrency proposal. This protocol has no actual code, and its purpose is to "mark" which types are safe to use in a concurrent environment. It looks like Swift is taking pointers from Rust. Specifically Rust's send/sync traits. There's even other keywords like unsafe in Swifts new `UnsafeSendable` for Sendable types that bypass compile time checks.

correct_horse 5y ago
Unsurprising, since the creator of rust, Graydon Hoare now works for apple on swift[0] in "a non-leadership position". [0] https://old.reddit.com/r/rust/comments/7qels2/i_wonder_why_graydon_hoare_the_author_of_rust/ https://old.reddit.com/r/rust/comments/7qels2/i_wonder_why_g...
- fay59 5y ago
  I believe that Graydon left Apple a while ago, but following compiler Twitter, it’s pretty clear that the rust folks and Swift folks are usually in good terms.
  - monocasa 5y ago
    You don't by chance know a list of handles to follow to get started following "compiler Twitter"?
    - fay59 5y ago
      I would recommend @johnregehr, @shafikyaghmour and @trav_downs if you're new to the area. If you're particularly interested in rust, @myrrlyn, @ManishEarth and @steveklabnik are great follows. @jfbastien is a compiler dad-joker extraordinaire and @jckarter is a master shitposter (with a side of old Macs) if you're in need of compiler-oriented comic relief. In particular, John tends to get involved in a lot of interesting conversations, so he's great to find more people to follow.
  - jamil7 5y ago
    I believe a few apple employees also contribute to Rust right? Seems to be quite a bit of crossover.
codetrotter 5y ago
Swift and Rust have a very similar feel to them, and I love both of them. There is no doubt that there is a lot of cross pollination between the two. And at least one person that was involved in creating Rust now works on developing the Swift language.
- jamil7 5y ago
  Can you comment on compile time for both in your experience? Larger Swift and SwiftUI projects are bring my (new) mac to a grinding halt and I’m finding myself working around things I know will be difficult for the compiler.
  - terhechte 5y ago
    I'm using both a lot. Rust has better compile times than Swift. It is especially not prone to these "one expression takes 60 seconds" scenarios. Although I feel that things have improved considerably with Xcode 13 beta. On the Rust side, there's an (almost-done) alternative compiler backend called Cranelift that brings 30-50% faster compile times for debug builds. This improves the iteration time considerably. https://news.ycombinator.com/item?id=25130528 https://news.ycombinator.com/item?id=25130528
pjmlp 5y ago
The concept of unsafe keywords in systems programming languages goes back all the way to 1960. Rust might have brought many interesting concepts into mainstream, however unsafe wasn't one of them.
- monocasa 5y ago
  That combined with marking types as Sendable points strongly at Rust influence. Then when you know that literal Graydon Hoare is working at Apple on Swift, the Rust influence is undeniable.
  - trevor-e 5y ago
    The Unsafe API has existed since Swift 1 which predates Graydon joining, and `UnsafeSendable` is just following the language naming conventions.
    - monocasa 5y ago
      Perhaps this is exposing a gap in my knowledge of programming language history, but I'm not aware of other languages that mark types as threadsafe with an otherwise empty Send(able) implementation.
      - pjmlp 5y ago
        See Concurrent Haskell as possible set of ideas how typeclasses can be used to constrain the set of operations and sequences a type can perform.
        monocasa 5y ago
        But that's pretty different, since normal code in that context uses immutable data structures and the channels, etc. are language features. You then don't have to tack something like Send(able) onto arbitrary types because they're immutable anyway. The whole point of Send(able) is thread safety in the face of generally mutable state in contrast to something like Concurrent Haskell.
saagarjha 5y ago
> There's even other keywords like unsafe in Swifts new `UnsafeSendable` for Sendable types that bypass compile time checks. Swift has used the “Unsafe” prefix for a very long time to indicate things that break its safety model, see for example the UnsafePointer APIs.
layer8 5y ago
Using empty interfaces (protocols) as markers is a longstanding practice in Java [0], although nowadays it is considered an antipattern and annotations are preferred. [0] https://en.wikipedia.org/wiki/Marker_interface_pattern https://en.wikipedia.org/wiki/Marker_interface_pattern
tomovo 5y ago
> taking pointers from Rust Surely you meant borrowing.

correct_horse 5y ago

I'm not sure if the author of this blog visits hacker news to read this, but your code blocks are unreadable without javascript. They're black highlighted black text.

bnchrch 5y ago
If you remove the wheels from a car don’t expect a smooth ride.
- deleted 5y ago
  [deleted]
- wott 5y ago
  Very unsuitable analogy. If you remove syntax colouring from a text, you do expect to still be able to read the text. Why the difference? Because the wheel is an essential component of a car, while syntax colouring is more akin to the paint job of the car: you change change it, remove it, it won't affect the function of the car. BTW, if we remove the CSS, the text becomes apparent again. So if we keep going with the same analogy, it becomes even more unsuitable: removing half of the wheels prevents the car from working, but removing all of them now restores a smooth ride. We quickly see how it turns absurd and contradicts.
nyanpasu64 5y ago
The site loads smoothly even with JS on. If you want to fix the code blocks with JS off, try the following: pre { background-color: rgb(40, 40, 35); color: rgb(248, 248, 242); }

kjaleshire 5y ago

Swift actors seem to differentiate from other actor implementations (see Erlang) which have a decoupled message queue. Calling into a Swift actor may be non-blocking, but the result must still be await'd and from the actor's perspective all calls are sequential and synchronous. By this token, actors seem to be the language-level implementation of a class where all methods are asynchronous, and also being protected by the same lock. The novel feature seems to be cooperative scheduling amongst actors.

jnwatson 5y ago
They seem to have done a great job of combining async with multithreading by using the actor pattern which is really smart. They also seem to have an m-to-n scheduler (not sure if in user space or kernel), so you can have more actors than “threads”.
- bsaul 5y ago
  After having tried to follow the discussions on swift forums on concurrency and actors, i still couldn't make my mind on whether their design was "fancy" smart (aka : something subtle and brilliant, that few developpers will get their grasp on and lead to inscrutable concurrency bugs), or "stupid" smart (aka : take a complex problem and make it look simple). Actors in systems like erlang seem to make concurrency simple, and the model seems to be easy to grasp. On the contrary, a few code samples i've seen on swift forums made my mind twist trying to understand how the code was going to be executed..
  - dwaite 5y ago
    The big difference AFAIK with Erlang (other than reference types) is that Swift's model is reentrant, while Erlang's is not. This is why `await` is such an important keywords to litter around your code - anything can happen in between when you await and when you come back, including actor message processing. You could have another invocation against your actor instance happen in tandem. This definitely increases the learning curve, but likely still saves time later when you are fighting various deadlock conditions.

galaxyLogic 5y ago

"Actors is a feature that is part of Swift's Structured Concurrency, bringing a brand new format to write and deal with asynchronous cod" , Brand new? I thought Carl Hewitt invented Actors https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model

ramchip 5y ago
The next sentence immediately says: > Although what Swift brings is new to the language, it's not new to tech itself. I think it's pretty clear that the author meant "brand new to Swift"?
- galaxyLogic 5y ago
  What I would have liked to have read is how their Swift Actors relate to or differ from the other existing models.

b3morales 5y ago

It seems to me there's some real cognitive dissonance in the fact that Swift is promoted as a systems programming language, but its facilities are insufficient to implement its own runtime. I like the language well enough, but there's a lot of "almost-but-not-quite" frustrations about it in that domain. Bit of a tangent, I suppose, but I was disappointed to see that the actor implementation continues enlarging the C++ core of the language. I also think that combines with the fact that the project is, in reality, controlled by Apple and not truly open, to create an extraordinarily high bar for contribution. I think the very narrow needle it's trying to thread between its base case as a GUI applications environment and other types of programs may end up dooming it. You can't please all the people all the time...