16 ms·

Swift Distributed Actors

168 points by samcat116 5y ago

Thaxll 5y ago
So Swift is pretty much dead in the backend space and somehow they're pushing actors in the language? I just don't understand the vision.
- johnnycerberus 5y ago
  Why do you think it is dead? I have always thought that it is incomplete as a language, just give it time. Swift seems to be my cup of tea after years of Java and Typescript. I would really like to learn about these new features and apply them in a backend scenario. Julia is another language that did not catch up as people expected (especially the data science community) but I enjoy using it for my personal projects, that does not mean it is dead.
  - eigenspace 5y ago
    > Julia is another language that did not catch up as people expected Wait what? Julia has been growing very consistently for years now. I don’t think anyone with a reasonably informed opinion thought Julia was going to take over the whole world in the blink of an eye. It seems to be going right along the lines that most people I know in the community expected.
ProfHewitt 5y ago
Swift Actors are an important contribution to the Actor Paradigm. There is is an upcoming keynote address on the Actor Paradigm at the Linux 30th Anniversary Conference. See https://reactivesummit2021.sched.com https://reactivesummit2021.sched.com
dunham 5y ago
How does security work with this? It looks like the actors can talk to each other over the network, but I don't see any means of authentication.
- bitwalker 5y ago
  Just like in Erlang, you would handle that at the transport level, and it appears Swift supports providing your own transports. They didn't mention (or I didn't see) whether the transport they are shipping has any specific auth wrapped around it though.
ecs78 5y ago
Yes, this is basically the new non-ObjC Distributed Objects or high level XPC interface.
arcticbull 5y ago
Woah, very cool - I guess Distributed Objects is getting a facelift and making a comeback. [1] What's old is new again, as they say. [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/DistrObjects/Concepts/architecture.html#//apple_ref/doc/uid/20000760-CJBEJBHH https://developer.apple.com/library/archive/documentation/Co...
- nielsbot 5y ago
  DO was super cool... Made things very easy. That said, I guess Swift is trying to do a better version of DO.
  - pjmlp 5y ago
    RMI did it first, actually. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere > By the time DOE, now known as NEO, was released in 1995, Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework, but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.
DenseComet 5y ago
This seems like a super interesting feature to have as part of a language. I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly targets server-side programming. However it seems right now its tied to much to just iOS development and Xcode, which doesn't make for a great experience using it for other things.
- tempodox 5y ago
  Right, you will never get your hands on a newer Swift compiler without also installing a whole new macOS with it, which is unacceptable for me. It's a shame, because Swift isn't a bad language.
- DrBenCarson 5y ago
  > Konrad Malawski is a member of a team developing foundational server-side Swift libraries at Apple, with focus on distributed systems and concurrency
  - eklavya 5y ago
    If I am not wrong he also worked on Akka, the distributed actors library for Scala.
    - acjohnson55 5y ago
      Yep, absolutely! He did fantastic work for Akka. Didn't realize he had left the Scala world, but good for him for taking the vision to other ecosystems.
    - drewhk 5y ago
      No, you are not wrong: https://akka.io/team/ https://akka.io/team/ (check the Honorary Members section)
- ternaryoperator 5y ago
  > I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly targets server-side programming. I hope for this too. I did a personal project in Swift on Linux and found that I loved the language. However, I was greatly frustrated by the lack of libraries. For Swift to reach the mainstream, IMHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I would vote for that even ahead of adding new features to the language.
Decabytes 5y ago
How is the Swift experience outside of the Apple ecosystem? And how does it compare to other languages like C# and Java?
- LASR 5y ago
  Pretty bad. In my last company we tried to get server-side swift integrated into a backend microservice. While there is big-company momentum behind swift on servers, it’s always a second-class citizen compared to its own native platforms (iOS & macOS). After IBM stopped backing it, pretty much killed credibility in server-side swift. We switched over to Rust fairly early on, and we were glad we did. I think the realization was that client-side app engineering is just different from distributed back-end systems. On iOS, we have a very rich set of standard toolkits we can consume. So development is fast and streamlined. Battle-hardened. But with swift on servers, you’re reinventing the wheel for even the most basic things. So it may very well be a completely different language on the backend at that point.
- chrismsimpson 5y ago
  I was perusing the implementation of String the other day and it’s intrinsically linked to the ObjC runtime to allow toll free bridging. The multi platform story for Swift is non existent.
  - jshier 5y ago
    This is only true on Apple platforms. String, of course, exists on all platforms. Of all the issues Swift's cross platform story has, this isn't one.
- Zababa 5y ago
  For web backend, I like Swift better as a language, but the ecosystem and the performance are not really here. The compilation times are also a bit annoying.
alexashka 5y ago
Where is the side to side comparison of features and to-do between this and existing distributed actor implementations, such as erlang + otp or java and whatever thing it uses? This approach of ignoring the rest of the world and explaining Swift concepts as if they exist in a vacuum is frustrating and counter-productive. Even if this were a totally new feature, I'd expect links to research papers. It is one thing to present end users with 'shiny new iphone' every year. It is another to treat developers like idiots and have every swift related announcement be this sales pitch of 'great new feature' when in reality they are all features other languages have had for decades (and are thus mature, while Swift is always half-baked and full of gotchas) and this is yet another re-implementation of what already exists with undocumented arbitrary differences that people then have to spend time to figure out (aka free beta test) when I'm sure the people who implement this stuff (hopefully) know full well what trade-offs they are making.
- watermelon0 5y ago
  I skimmed through the blog post, and it seems to me that they are not claiming they invented something new, just that they are adding this to Swift language. (Distributed) actor model is nothing new, but I definitely wouldn't classify it as something that's common in other languages. To my knowledge Erlang/OTP is the only mainstream language where this is part of the standard library. There are implementations for other languages, such as Akka for Java/Scala and Orleans for dotnet, but most languages (sadly) don't have a battle-tested implementation of this.
  - teakettle42 5y ago
    > most languages (sadly) don't have a battle-tested implementation of this. I’d argue that this is because it’s a failed idea that conflates OO encapsulation, concurrency constraints, identity, serialization, and networking into a behemoth that does none of those things well.
  - alexashka 5y ago
    They are adding features they 'took' to put it kindly from other existing, mature implementations without giving any credit or acknowledgement. Not only that, they expect people to test their beta grade software because they keep releasing it half baked ever since the release of Swift itself. It's embarrassing and it also angers me because these companies have wall gardened their ecosystems to proprietary languages and tools that all do the same thing poorly, differently and in ways that prevent sane cross platform development, on purpose, this being yet another apple-only 'thing'. Here's Swift's roadmap: copy C# and other languages for the next 5 years while making sure you can't write cross platform code by adding arbitrary garbage like SwiftUI or this 'distributed actor' implementation that will surely differ and not be compatible with existing features of other languages and their tooling.
snicker7 5y ago
This sort of language cruft makes me realize that Lisp had it right all along.
- darthrupert 5y ago
  Yet somehow the Lisps seem to be doing all sorts of concurrency rather poorly.
  - eyelidlessness 5y ago
    (@clojure would like to have [a few words])
  - Arcanum-XIII 5y ago
    Beside Clojure, Common Lisp has nice library addressing this issue — and of course the commercial version have their own too.
  - fractallyte 5y ago
    Not necessarily: https://lfe.io/ https://lfe.io/ Lisp Flavoured Erlang! ;-)
rurban 5y ago
I would name the "distributed" actor and func keyword "remote" instead. It's shorter and more understandable.
- eyelidlessness 5y ago
  Even in traditional Actor model systems processes aren’t remote by default. They just allow you to reason about remote concurrency the same way you reason about it generally.
  - ProfHewitt 5y ago
    The Actors Abstraction does not require specification of computer boundaries.
    - eyelidlessness 5y ago
      Unless I’m missing something this is exactly what I was saying? I’m open to the possibility I’m missing something, but my understanding is that Actor boundaries are messenger boundaries and they can be remote, or local processes, or event loop routines, or plain local functions with no real concurrency. The abstraction/model only enforces that communication between them is consistent no matter the actor’s environment.
orasis 5y ago
After using a data structure first framework like Dask I can’t imagine ever going back to an actor oriented approach.
- ecs78 5y ago
  You still have value semantics to lean on. They integrate really well with Swift’s actor implementation.
- deleted 5y ago
  [deleted]
guerrilla 5y ago
So wasn't this part of the original dream for Smalltalk? Then this would seem to be coming full circle: Smalltalk, Objective C, Swift and back. I know some of you are Alan Kay fans so maybe you can comment on that aspect.
- tytrdev 5y ago
  Yes, but only a part. It’s not just about having something akin to actors for concurrency and execution. It’s also about having a dynamic system - one that can update its behavior not just by manual request, but automatically as the system is running. One way to think about this is propagators. I’m still learning myself, but a compelling example is lisp. With lisp you can write macros that essentially allow you to treat your code as a tree and arbitrarily modify that tree (aka arbitrarily write code). You can then compile that code while the system is running and execute it. It’s not just about macro expansion at startup or a single compile time step at the beginning of execution. The system can be designed with this in mind. It’s also about introspection, the ability to ask questions about the system at runtime as it evolves. Sussman and Kay both talk a lot about DNA and biology, and the ability for systems to dynamically expand, change, and repair themselves. When I think about this kind of stuff nowadays I picture something like lisp with an execution environment like the BEAM (so basically LFE) and an introspection system powered by a declarative constraint solving query language (something like Datalog-style RDF found in things like datalevin and it’s predecessors). I think that lends itself really well to these kinds of systems, including another point that Kay talks about pretty frequently. The ability for two systems (and in our cases two actors in one environment count) to negotiate with each other via some shared fundamental language to understand each other’s purpose. SOP style approaches seem like a compelling way to do that, but the main problem to me is identifying entities as globally unique as part of that negotiation process. Also don’t listen to me, I’m a monkey.
  - ProfHewitt 5y ago
    Probably can't make much progress without a scientific foundation including the Actors Abstraction.
- igouy 5y ago
fulafel 5y ago
What's the TLDR on why this is a language feature vs a library?
- dmitriid 5y ago
  Anything concurrent and distributed you want supported by your runtime a la Erlang. The reason is: you want certain guarantees. For example, in Erlang you can set up a monitor on a process, and when that process exits for any reason, you get a notification, {EXIT, Reason}. Even if that reason was a catastrophic failure of some sort. If this is implemented as a library, then the runtime can kill your code at any time, and you'll never know what happened.
  - ProfHewitt 5y ago
    Erlang has absolutely no security :-(
    - fulafel 5y ago
      So what kind of security does this have? The article doesn't mention the term.
  - acjohnson55 5y ago
    I don't know if that's true. In the Scala and Java worlds, a library called Akka provides distributed actors as a library. As far as I know, what you describe isn't a limitation. See https://doc.akka.io/docs/akka/2.5.32/general/supervision.html#what-lifecycle-monitoring-means https://doc.akka.io/docs/akka/2.5.32/general/supervision.htm...
    - dmitriid 5y ago
      It is a limitation. If the VM on the other machine is killed, or kills the thread, you'll never know that happened, and why. Well, you can probably ping the process and what not :) Compare Erlang's error handling and monitors: https://erlang.org/doc/reference_manual/processes.html#error-handling https://erlang.org/doc/reference_manual/processes.html#error...
nyanpasu64 5y ago
How does this compare to DCOM? (disclaimer, I've never used it)
- pjmlp 5y ago
  Much better. Consider yourself lucky not having to deal with raw IDL without VS tooling and ATL template metaprogramming.
bsaul 5y ago
Nice to see swift trying to make a dent in server programming using shiny new features, however i would have liked something on the android side instead. Being able to reuse code between ios and android, including foundation api, would have made an easy way to grow the user base. it's going to be hard to put swift in the hands of go or kotlin devs..
- mojuba 5y ago
  There was once a really nice open source cross-platform framework called Apportable that provided an Obj-C compatibility layer on Android. You could develop your app on iOS and then last moment build it on Android with some minimal changes. I tried it for one of my projects and it worked just great. Guess what happened to Apportable? It was quietly acquired by Google and completely shut down within days, with practically no traces left on GitHub or the rest of the Internet. This is because Google will be hostile to any compatibility layer that places iOS in a privileged position and makes Android a second-class citizen, an afterthought in your development process. With this story in mind, I don't think Apple would step into that territory.
  - bsaul 5y ago
    I don’t see how they would block apple from providing a good experience without crippling the whole NDK community
    - pjmlp 5y ago
      NDK is already crippled by design. https://developer.android.com/ndk/guides https://developer.android.com/ndk/guides > Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations. > Reuse your own or other developers' C or C++ libraries. Using this set of public APIs: https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Anything else is going into the "works on my device dunno about your's" territory.
rektide 5y ago
if making such things a language feature is what you need to do then fine, but for a lot of languages with good meta (like javascript's proxies) one should be able to build things with similar ergonomics & capabilities without having to expand the language.
eob 5y ago
Question for folks: where do server-side Swift folks hang out? I've been writing server-side / enterprise code in Swift for about a year now, and the language has really grown on me. But it's a small community, and IBM's & Google's departures were a big blow to the feeling of inevitable growth to it. I'd love to find a watering hole to chat with others in the same small niche.
- b3morales 5y ago
  I understand that there's a public Slack group for server-side Swift. I do not know the invite URL, but you may be able to find it in a search?
- 0xTim 5y ago
  Here's an invite for the main Swift server Slack that's not just Vapor https://join.slack.com/t/swift-server/shared_invite/zt-5jv0mzlu-1HnA~7cpjL6IfmZqd~yQ2A https://join.slack.com/t/swift-server/shared_invite/zt-5jv0m...
- AndroidKitKat 5y ago
  You might some likeminded people in the Vapor Discord Server [1]. They've got channels for all the budding Swift tech. [1]: https://discord.gg/vapor https://discord.gg/vapor
eternalban 5y ago
There is an existing, influential, paper called "A Note on Distributed Computing" that hugely influenced Java (and other) languages and frameworks that argued precisely against abstracting away remoteness. The Swift team seems to be challenging that thesis: "[U]nlike other concurrency models, the actor model is also tremendously valuable for modeling distributed systems. Thanks to the notion of location transparent distributed actors, we can program distributed systems using the familiar idea of actors and then readily move it to a distributed, e.g., clustered, environment. With distributed actors, we aim to simplify and push the state of the art of distributed systems programming, the same way we did with concurrent programming with local actors and Swift’s structured concurrency models embedded in the language. This abstraction does not intend to completely hide away the fact that distributed calls are crossing the network, though. In a way, we are doing the opposite and programming assuming that calls may be remote. This small yet crucial observation allows us to build systems primarily intended for distribution and testable in local test clusters that may even efficiently simulate various error scenarios. Distributed actors are similar to (local) actors because they encapsulate their state with communication exclusively through asynchronous calls. The distributed aspect adds to that equation some additional isolation, type system, and runtime considerations. However, the surface of the feature feels very similar to local actors." Amusingly, in a section immediately followed by "Deja Vu All Over Again", Waldo et al. write: "One conceptual justification for this vision is that whether a call is local or remote has no impact on the correctness of a program. If an object supports a particular interface, and the support of that interface is semantically correct, it makes no difference to the correctness of the program whether the operation is carried out within the same address space, on some other machine, or off-line by some other piece of equipment. Indeed, seeing location as a part of the implementation of an object and therefore as part of the state that an object hides from the outside world appears to be a natural extension of the object-oriented paradigm. Such a system would enjoy many advantages. It would allow the task of software maintenance to be changed in a fundamental way. The granularity of change, and therefore of upgrade, could be changed from the level of the entire system (the current model) to the level of the individual object. As long as the interfaces between objects remain constant, the implementations of those objects can be altered at will. Remote services can be moved into an address space, and objects that share an address space can be split and moved to different machines, as local requirements and needs dictate. An object can be repaired and the repair installed without worry that the change will impact the other objects that make up the system. Indeed, this model appears to be the best way to get away from the “Big Wad of Software” model that currently is causing so much trouble. This vision is centered around the following principles that may, at first, appear plausible: • there is a single natural object-oriented design for a given application, regardless of the context in which that application will be deployed; • failure and performance issues are tied to the implementation of the components of an application, and consideration of these issues should be left out of an initial design; and • the interface of an object is independent of the context in which that object is used. Unfortunately, all of these principles are false. In what follows, we will show why these principles are mistaken, and why it is important to recognize the fundamental differences between distributed computing and local computing." RMI, some may recall, was heavily influenced by the above critique which lead to the very verbose and ceremonial characteristics of Sun's Java distributed system's APIs that were later criticized as cumbersome. [1]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7628 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7... [2]: http://www.cs.yale.edu/homes/aspnes/classes/465/notes.pdf http://www.cs.yale.edu/homes/aspnes/classes/465/notes.pdf
The_rationalist 5y ago
It needs a comparison with AKKA
frobisher 5y ago
This reminds me a lot of Erlang/Elixir's distributed processes: https://elixir-lang.org/getting-started/mix-otp/distributed-tasks.html https://elixir-lang.org/getting-started/mix-otp/distributed-....
nsonha 5y ago
for a niche language swift seems kind of bloated. Why do you need a special actor keyword? isn't it just object with a global/distributed registry or something?
halfmatthalfcat 5y ago
This is awesome, I'm always looking for more competition in the distributed actor model/system space. So now we'll have Akka, Elixir, Erlang and Swift as options. Pretty exciting! edit: Rust's Actix too! edit2: jk Actix is only local.
- teakettle42 5y ago
  I’m the pessimistic opposite here; I’m a little shocked to see this largely failed idea be dragged back out of the history books again, a good decade-plus after the last major failed attempt. We’ve gone through this so many times, and — outside the very specialized Erlang — the result is always the same. It doesn’t work. OO Actors are a terrible concurrency model, and an even worse networking, protocol definition, and serialization model.
  - johnnycerberus 5y ago
    Erlang nailed the actor model.
    - ProfHewitt 5y ago
      Erlang incorporated some of the ideas of the Actor Abstraction but missed a few things. See See article and video here: https://papers.ssrn.com/abstract=3603021 https://papers.ssrn.com/abstract=3603021 https://www.youtube.com/watch?v=AJP1VL7shiI https://www.youtube.com/watch?v=AJP1VL7shiI
  - halfmatthalfcat 5y ago
    I've used Akka extensively and beg to differ. It's such a clean departure from traditional concurrent programming and the "let it fail" mentality around it is real. The distributed features work as intended to great effect with only certain edge cases (split brain for example) that need to have care but at that point in scale, you're already leveraging all the best parts.
    - rektide 5y ago

168 points by samcat116 5y ago

So Swift is pretty much dead in the backend space and somehow they're pushing actors in the language? I just don't understand the vision.

johnnycerberus 5y ago
Why do you think it is dead? I have always thought that it is incomplete as a language, just give it time. Swift seems to be my cup of tea after years of Java and Typescript. I would really like to learn about these new features and apply them in a backend scenario. Julia is another language that did not catch up as people expected (especially the data science community) but I enjoy using it for my personal projects, that does not mean it is dead.
- eigenspace 5y ago
  > Julia is another language that did not catch up as people expected Wait what? Julia has been growing very consistently for years now. I don’t think anyone with a reasonably informed opinion thought Julia was going to take over the whole world in the blink of an eye. It seems to be going right along the lines that most people I know in the community expected.

ProfHewitt 5y ago

Swift Actors are an important contribution to the Actor Paradigm. There is is an upcoming keynote address on the Actor Paradigm at the Linux 30th Anniversary Conference. See https://reactivesummit2021.sched.com https://reactivesummit2021.sched.com

dunham 5y ago

How does security work with this? It looks like the actors can talk to each other over the network, but I don't see any means of authentication.

bitwalker 5y ago
Just like in Erlang, you would handle that at the transport level, and it appears Swift supports providing your own transports. They didn't mention (or I didn't see) whether the transport they are shipping has any specific auth wrapped around it though.

ecs78 5y ago

Yes, this is basically the new non-ObjC Distributed Objects or high level XPC interface.

arcticbull 5y ago

Woah, very cool - I guess Distributed Objects is getting a facelift and making a comeback. [1] What's old is new again, as they say. [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/DistrObjects/Concepts/architecture.html#//apple_ref/doc/uid/20000760-CJBEJBHH https://developer.apple.com/library/archive/documentation/Co...

nielsbot 5y ago
DO was super cool... Made things very easy. That said, I guess Swift is trying to do a better version of DO.
- pjmlp 5y ago
  RMI did it first, actually. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere > By the time DOE, now known as NEO, was released in 1995, Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework, but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.

DenseComet 5y ago

This seems like a super interesting feature to have as part of a language. I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly targets server-side programming. However it seems right now its tied to much to just iOS development and Xcode, which doesn't make for a great experience using it for other things.

tempodox 5y ago
Right, you will never get your hands on a newer Swift compiler without also installing a whole new macOS with it, which is unacceptable for me. It's a shame, because Swift isn't a bad language.
DrBenCarson 5y ago
> Konrad Malawski is a member of a team developing foundational server-side Swift libraries at Apple, with focus on distributed systems and concurrency
- eklavya 5y ago
  If I am not wrong he also worked on Akka, the distributed actors library for Scala.
  - acjohnson55 5y ago
    Yep, absolutely! He did fantastic work for Akka. Didn't realize he had left the Scala world, but good for him for taking the vision to other ecosystems.
  - drewhk 5y ago
    No, you are not wrong: https://akka.io/team/ https://akka.io/team/ (check the Honorary Members section)
ternaryoperator 5y ago
> I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly targets server-side programming. I hope for this too. I did a personal project in Swift on Linux and found that I loved the language. However, I was greatly frustrated by the lack of libraries. For Swift to reach the mainstream, IMHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I would vote for that even ahead of adding new features to the language.

Decabytes 5y ago

How is the Swift experience outside of the Apple ecosystem? And how does it compare to other languages like C# and Java?

LASR 5y ago
Pretty bad. In my last company we tried to get server-side swift integrated into a backend microservice. While there is big-company momentum behind swift on servers, it’s always a second-class citizen compared to its own native platforms (iOS & macOS). After IBM stopped backing it, pretty much killed credibility in server-side swift. We switched over to Rust fairly early on, and we were glad we did. I think the realization was that client-side app engineering is just different from distributed back-end systems. On iOS, we have a very rich set of standard toolkits we can consume. So development is fast and streamlined. Battle-hardened. But with swift on servers, you’re reinventing the wheel for even the most basic things. So it may very well be a completely different language on the backend at that point.
chrismsimpson 5y ago
I was perusing the implementation of String the other day and it’s intrinsically linked to the ObjC runtime to allow toll free bridging. The multi platform story for Swift is non existent.
- jshier 5y ago
  This is only true on Apple platforms. String, of course, exists on all platforms. Of all the issues Swift's cross platform story has, this isn't one.
Zababa 5y ago
For web backend, I like Swift better as a language, but the ecosystem and the performance are not really here. The compilation times are also a bit annoying.

alexashka 5y ago

Where is the side to side comparison of features and to-do between this and existing distributed actor implementations, such as erlang + otp or java and whatever thing it uses? This approach of ignoring the rest of the world and explaining Swift concepts as if they exist in a vacuum is frustrating and counter-productive. Even if this were a totally new feature, I'd expect links to research papers. It is one thing to present end users with 'shiny new iphone' every year. It is another to treat developers like idiots and have every swift related announcement be this sales pitch of 'great new feature' when in reality they are all features other languages have had for decades (and are thus mature, while Swift is always half-baked and full of gotchas) and this is yet another re-implementation of what already exists with undocumented arbitrary differences that people then have to spend time to figure out (aka free beta test) when I'm sure the people who implement this stuff (hopefully) know full well what trade-offs they are making.

watermelon0 5y ago
I skimmed through the blog post, and it seems to me that they are not claiming they invented something new, just that they are adding this to Swift language. (Distributed) actor model is nothing new, but I definitely wouldn't classify it as something that's common in other languages. To my knowledge Erlang/OTP is the only mainstream language where this is part of the standard library. There are implementations for other languages, such as Akka for Java/Scala and Orleans for dotnet, but most languages (sadly) don't have a battle-tested implementation of this.
- teakettle42 5y ago
  > most languages (sadly) don't have a battle-tested implementation of this. I’d argue that this is because it’s a failed idea that conflates OO encapsulation, concurrency constraints, identity, serialization, and networking into a behemoth that does none of those things well.
- alexashka 5y ago
  They are adding features they 'took' to put it kindly from other existing, mature implementations without giving any credit or acknowledgement. Not only that, they expect people to test their beta grade software because they keep releasing it half baked ever since the release of Swift itself. It's embarrassing and it also angers me because these companies have wall gardened their ecosystems to proprietary languages and tools that all do the same thing poorly, differently and in ways that prevent sane cross platform development, on purpose, this being yet another apple-only 'thing'. Here's Swift's roadmap: copy C# and other languages for the next 5 years while making sure you can't write cross platform code by adding arbitrary garbage like SwiftUI or this 'distributed actor' implementation that will surely differ and not be compatible with existing features of other languages and their tooling.

snicker7 5y ago

This sort of language cruft makes me realize that Lisp had it right all along.

darthrupert 5y ago
Yet somehow the Lisps seem to be doing all sorts of concurrency rather poorly.
- eyelidlessness 5y ago
  (@clojure would like to have [a few words])
- Arcanum-XIII 5y ago
  Beside Clojure, Common Lisp has nice library addressing this issue — and of course the commercial version have their own too.
- fractallyte 5y ago
  Not necessarily: https://lfe.io/ https://lfe.io/ Lisp Flavoured Erlang! ;-)

rurban 5y ago

I would name the "distributed" actor and func keyword "remote" instead. It's shorter and more understandable.

eyelidlessness 5y ago
Even in traditional Actor model systems processes aren’t remote by default. They just allow you to reason about remote concurrency the same way you reason about it generally.
- ProfHewitt 5y ago
  The Actors Abstraction does not require specification of computer boundaries.
  - eyelidlessness 5y ago
    Unless I’m missing something this is exactly what I was saying? I’m open to the possibility I’m missing something, but my understanding is that Actor boundaries are messenger boundaries and they can be remote, or local processes, or event loop routines, or plain local functions with no real concurrency. The abstraction/model only enforces that communication between them is consistent no matter the actor’s environment.

orasis 5y ago

After using a data structure first framework like Dask I can’t imagine ever going back to an actor oriented approach.

ecs78 5y ago
You still have value semantics to lean on. They integrate really well with Swift’s actor implementation.
deleted 5y ago
[deleted]

guerrilla 5y ago

So wasn't this part of the original dream for Smalltalk? Then this would seem to be coming full circle: Smalltalk, Objective C, Swift and back. I know some of you are Alan Kay fans so maybe you can comment on that aspect.

tytrdev 5y ago
Yes, but only a part. It’s not just about having something akin to actors for concurrency and execution. It’s also about having a dynamic system - one that can update its behavior not just by manual request, but automatically as the system is running. One way to think about this is propagators. I’m still learning myself, but a compelling example is lisp. With lisp you can write macros that essentially allow you to treat your code as a tree and arbitrarily modify that tree (aka arbitrarily write code). You can then compile that code while the system is running and execute it. It’s not just about macro expansion at startup or a single compile time step at the beginning of execution. The system can be designed with this in mind. It’s also about introspection, the ability to ask questions about the system at runtime as it evolves. Sussman and Kay both talk a lot about DNA and biology, and the ability for systems to dynamically expand, change, and repair themselves. When I think about this kind of stuff nowadays I picture something like lisp with an execution environment like the BEAM (so basically LFE) and an introspection system powered by a declarative constraint solving query language (something like Datalog-style RDF found in things like datalevin and it’s predecessors). I think that lends itself really well to these kinds of systems, including another point that Kay talks about pretty frequently. The ability for two systems (and in our cases two actors in one environment count) to negotiate with each other via some shared fundamental language to understand each other’s purpose. SOP style approaches seem like a compelling way to do that, but the main problem to me is identifying entities as globally unique as part of that negotiation process. Also don’t listen to me, I’m a monkey.
- ProfHewitt 5y ago
  Probably can't make much progress without a scientific foundation including the Actors Abstraction.
igouy 5y ago

fulafel 5y ago

What's the TLDR on why this is a language feature vs a library?

dmitriid 5y ago
Anything concurrent and distributed you want supported by your runtime a la Erlang. The reason is: you want certain guarantees. For example, in Erlang you can set up a monitor on a process, and when that process exits for any reason, you get a notification, {EXIT, Reason}. Even if that reason was a catastrophic failure of some sort. If this is implemented as a library, then the runtime can kill your code at any time, and you'll never know what happened.
- ProfHewitt 5y ago
  Erlang has absolutely no security :-(
  - fulafel 5y ago
    So what kind of security does this have? The article doesn't mention the term.
- acjohnson55 5y ago
  I don't know if that's true. In the Scala and Java worlds, a library called Akka provides distributed actors as a library. As far as I know, what you describe isn't a limitation. See https://doc.akka.io/docs/akka/2.5.32/general/supervision.html#what-lifecycle-monitoring-means https://doc.akka.io/docs/akka/2.5.32/general/supervision.htm...
  - dmitriid 5y ago
    It is a limitation. If the VM on the other machine is killed, or kills the thread, you'll never know that happened, and why. Well, you can probably ping the process and what not :) Compare Erlang's error handling and monitors: https://erlang.org/doc/reference_manual/processes.html#error-handling https://erlang.org/doc/reference_manual/processes.html#error...

nyanpasu64 5y ago

How does this compare to DCOM? (disclaimer, I've never used it)

pjmlp 5y ago
Much better. Consider yourself lucky not having to deal with raw IDL without VS tooling and ATL template metaprogramming.

bsaul 5y ago

Nice to see swift trying to make a dent in server programming using shiny new features, however i would have liked something on the android side instead. Being able to reuse code between ios and android, including foundation api, would have made an easy way to grow the user base. it's going to be hard to put swift in the hands of go or kotlin devs..

mojuba 5y ago
There was once a really nice open source cross-platform framework called Apportable that provided an Obj-C compatibility layer on Android. You could develop your app on iOS and then last moment build it on Android with some minimal changes. I tried it for one of my projects and it worked just great. Guess what happened to Apportable? It was quietly acquired by Google and completely shut down within days, with practically no traces left on GitHub or the rest of the Internet. This is because Google will be hostile to any compatibility layer that places iOS in a privileged position and makes Android a second-class citizen, an afterthought in your development process. With this story in mind, I don't think Apple would step into that territory.
- bsaul 5y ago
  I don’t see how they would block apple from providing a good experience without crippling the whole NDK community
  - pjmlp 5y ago
    NDK is already crippled by design. https://developer.android.com/ndk/guides https://developer.android.com/ndk/guides > Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations. > Reuse your own or other developers' C or C++ libraries. Using this set of public APIs: https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Anything else is going into the "works on my device dunno about your's" territory.

rektide 5y ago

if making such things a language feature is what you need to do then fine, but for a lot of languages with good meta (like javascript's proxies) one should be able to build things with similar ergonomics & capabilities without having to expand the language.

eob 5y ago

Question for folks: where do server-side Swift folks hang out? I've been writing server-side / enterprise code in Swift for about a year now, and the language has really grown on me. But it's a small community, and IBM's & Google's departures were a big blow to the feeling of inevitable growth to it. I'd love to find a watering hole to chat with others in the same small niche.

b3morales 5y ago
I understand that there's a public Slack group for server-side Swift. I do not know the invite URL, but you may be able to find it in a search?
0xTim 5y ago
Here's an invite for the main Swift server Slack that's not just Vapor https://join.slack.com/t/swift-server/shared_invite/zt-5jv0mzlu-1HnA~7cpjL6IfmZqd~yQ2A https://join.slack.com/t/swift-server/shared_invite/zt-5jv0m...
AndroidKitKat 5y ago
You might some likeminded people in the Vapor Discord Server [1]. They've got channels for all the budding Swift tech. [1]: https://discord.gg/vapor https://discord.gg/vapor

eternalban 5y ago

There is an existing, influential, paper called "A Note on Distributed Computing" that hugely influenced Java (and other) languages and frameworks that argued precisely against abstracting away remoteness. The Swift team seems to be challenging that thesis: "[U]nlike other concurrency models, the actor model is also tremendously valuable for modeling distributed systems. Thanks to the notion of location transparent distributed actors, we can program distributed systems using the familiar idea of actors and then readily move it to a distributed, e.g., clustered, environment. With distributed actors, we aim to simplify and push the state of the art of distributed systems programming, the same way we did with concurrent programming with local actors and Swift’s structured concurrency models embedded in the language. This abstraction does not intend to completely hide away the fact that distributed calls are crossing the network, though. In a way, we are doing the opposite and programming assuming that calls may be remote. This small yet crucial observation allows us to build systems primarily intended for distribution and testable in local test clusters that may even efficiently simulate various error scenarios. Distributed actors are similar to (local) actors because they encapsulate their state with communication exclusively through asynchronous calls. The distributed aspect adds to that equation some additional isolation, type system, and runtime considerations. However, the surface of the feature feels very similar to local actors." Amusingly, in a section immediately followed by "Deja Vu All Over Again", Waldo et al. write: "One conceptual justification for this vision is that whether a call is local or remote has no impact on the correctness of a program. If an object supports a particular interface, and the support of that interface is semantically correct, it makes no difference to the correctness of the program whether the operation is carried out within the same address space, on some other machine, or off-line by some other piece of equipment. Indeed, seeing location as a part of the implementation of an object and therefore as part of the state that an object hides from the outside world appears to be a natural extension of the object-oriented paradigm. Such a system would enjoy many advantages. It would allow the task of software maintenance to be changed in a fundamental way. The granularity of change, and therefore of upgrade, could be changed from the level of the entire system (the current model) to the level of the individual object. As long as the interfaces between objects remain constant, the implementations of those objects can be altered at will. Remote services can be moved into an address space, and objects that share an address space can be split and moved to different machines, as local requirements and needs dictate. An object can be repaired and the repair installed without worry that the change will impact the other objects that make up the system. Indeed, this model appears to be the best way to get away from the “Big Wad of Software” model that currently is causing so much trouble. This vision is centered around the following principles that may, at first, appear plausible: • there is a single natural object-oriented design for a given application, regardless of the context in which that application will be deployed; • failure and performance issues are tied to the implementation of the components of an application, and consideration of these issues should be left out of an initial design; and • the interface of an object is independent of the context in which that object is used. Unfortunately, all of these principles are false. In what follows, we will show why these principles are mistaken, and why it is important to recognize the fundamental differences between distributed computing and local computing." RMI, some may recall, was heavily influenced by the above critique which lead to the very verbose and ceremonial characteristics of Sun's Java distributed system's APIs that were later criticized as cumbersome. [1]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7628 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7... [2]: http://www.cs.yale.edu/homes/aspnes/classes/465/notes.pdf http://www.cs.yale.edu/homes/aspnes/classes/465/notes.pdf

The_rationalist 5y ago

It needs a comparison with AKKA

frobisher 5y ago

This reminds me a lot of Erlang/Elixir's distributed processes: https://elixir-lang.org/getting-started/mix-otp/distributed-tasks.html https://elixir-lang.org/getting-started/mix-otp/distributed-....

nsonha 5y ago

for a niche language swift seems kind of bloated. Why do you need a special actor keyword? isn't it just object with a global/distributed registry or something?

halfmatthalfcat 5y ago

This is awesome, I'm always looking for more competition in the distributed actor model/system space. So now we'll have Akka, Elixir, Erlang and Swift as options. Pretty exciting! edit: Rust's Actix too! edit2: jk Actix is only local.

teakettle42 5y ago
I’m the pessimistic opposite here; I’m a little shocked to see this largely failed idea be dragged back out of the history books again, a good decade-plus after the last major failed attempt. We’ve gone through this so many times, and — outside the very specialized Erlang — the result is always the same. It doesn’t work. OO Actors are a terrible concurrency model, and an even worse networking, protocol definition, and serialization model.
- johnnycerberus 5y ago
  Erlang nailed the actor model.
  - ProfHewitt 5y ago
    Erlang incorporated some of the ideas of the Actor Abstraction but missed a few things. See See article and video here: https://papers.ssrn.com/abstract=3603021 https://papers.ssrn.com/abstract=3603021 https://www.youtube.com/watch?v=AJP1VL7shiI https://www.youtube.com/watch?v=AJP1VL7shiI
- halfmatthalfcat 5y ago
  I've used Akka extensively and beg to differ. It's such a clean departure from traditional concurrent programming and the "let it fail" mentality around it is real. The distributed features work as intended to great effect with only certain edge cases (split brain for example) that need to have care but at that point in scale, you're already leveraging all the best parts.
  - rektide 5y ago