It's actually more like Akka, but integrated into the language instead of a library, though the transport is still abstracted and replaceable. Interestingly enough, Konrad (ktoso) is an ex Akka developer.
Pretty excited for this. Looks like a good alternative to Erlang or Akka with the native performance / low resource utilization of Swift. Erlang lacks strong typing and Akka is DSL-hell. Both Erlang and Akka/JVM are GC languages whereas Swift uses atomic reference counting.
Looks like they've open-sourced a transport [0] and are adding support for distributed tracing as well [1, 2], which is a huge aid for system operators and debugging.
Small question, what are the use cases? From what I understand (I might be wrong), distributed actors is a way to distribute your actors on multiple computers. And again, from what I understand, Swift is mostly used for stuff that runs on one computer, usually an Apple device. To me, distributed actors is something that you need when you build backend stuff. Is Apple planning to use Swift for their backends? Or are they trying to push more the language in general? I can find a bit more information here (https://github.com/apple/swift-evolution/blob/main/proposals...):
> With distributed actors, we acknowledge that the world we live in is increasingly built around distributed systems, and that we should provide developers with better tools to work within those environments. We aim to simplify and push the state-of-the-art for distributed systems programming in Swift as we did with concurrent programming with local actors and Swift’s structured concurrency approach embedded in the language.
But this seems like a "it's a good thing to have" rather than "we need this to do that". This is not to question the choice to add those to Swift, I'm just curious about the use cases. I've done a bit of Swift and I like the language a lot. If this means that we'll see more Swift on the backend, I'm excited for it.
I read about the distributed actors and my first thought was "a semi standalone headset that needs to communicate with the phone and/or watch" could probably benefit from this.
Swift's use case for backend are those iDevice apps that also need to talk to something, so even if that is the only use case Apple cares about Swift on Linux, it is already a bigger number than many languages can aspire to.
6 comments
[ 5.9 ms ] story [ 29.3 ms ] threadLooks like they've open-sourced a transport [0] and are adding support for distributed tracing as well [1, 2], which is a huge aid for system operators and debugging.
[0] https://github.com/apple/swift-distributed-actors/ [1] https://apple.github.io/swift-distributed-actors/1.0.0-beta.... [2] https://github.com/apple/swift-distributed-tracing
> With distributed actors, we acknowledge that the world we live in is increasingly built around distributed systems, and that we should provide developers with better tools to work within those environments. We aim to simplify and push the state-of-the-art for distributed systems programming in Swift as we did with concurrent programming with local actors and Swift’s structured concurrency approach embedded in the language.
But this seems like a "it's a good thing to have" rather than "we need this to do that". This is not to question the choice to add those to Swift, I'm just curious about the use cases. I've done a bit of Swift and I like the language a lot. If this means that we'll see more Swift on the backend, I'm excited for it.