Earlier quoted context omitted.
is Actix distributed?
Actually no, I misspoke. Looks like they're just local.
I think there are crates that enable it, but like via 3p stuff like redis (but I don't know enough about rust to be certain)
Swift Distributed Actors
91–100 of 135 posts
Re: Swift Distributed Actors
#92Earlier quoted context omitted.
My experience is the opposite: using Swift for Apple ecosystem development basically removed all of the benefits that Swift the language offered. It’s clearly designed as a general purpose language, and its adoption mostly curtailed by this reputation.
I’ve been using Swift to develop Apple software since 2014. I’ve released quite a few apps, written with it. Before that, I used ObjC. I’m extremely happy with Swift. As far as adoption goes, many large codebases are likely still ObjC; simply because of hysteresis. Major architectural shifts take a lot of time, money and risk. That’s one reason I don’t feel that much urgency to jump on the SwiftUI/Async stuff (but I…
To be clear, I quite like Swift and did from day 1. Granted I’ve only tinkered with it. What I didn’t like was interacting with Cocoa APIs. I found it difficult to use Swift’s protocols and structs in a FP style, because Cocoa isn’t designed that way.
I imagine this has gotten a lot better since, particularly with stuff like Swift UI. That said, I’d personally find Swift more compelling to use as a server language.
Re: Swift Distributed Actors
#93Swift 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
Re: Swift Distributed Actors
#94Earlier quoted context omitted.
I’ve been using Swift to develop Apple software since 2014. I’ve released quite a few apps, written with it. Before that, I used ObjC. I’m extremely happy with Swift. As far as adoption goes, many large codebases are likely still ObjC; simply because of hysteresis. Major architectural shifts take a lot of time, money and risk. That’s one reason I don’t feel that much urgency to jump on the SwiftUI/Async stuff (but I…
In my last job until I retired this year, I spent 5.5 years writing only Swift at a large (not FAANG) company. It took the entire mobile team about that time to retire most of the Obj-C codebase(s). Swift is by far my favorite language despite having spent decades with C/C++/Java and Obj-C. I am still writing Swift despite being retired but as part of my art generation work now.
> I am still writing Swift despite being retired but as part of my art generation work now.
Anything publicly available? I’m always looking for more generative art!
Re: Swift Distributed Actors
#95Earlier quoted context omitted.
> MHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I suspect Apple is trying to do this for straightforward reasons like wanting to remain relevant and foster community growth as to retain credibility… while also subtly trying to not encourage the use of Swift as a language for any other GUI framework/platform than Cocoa + macOS. Obviously I don’t have any evidence t…
My understanding (and I invite correction if I'm mistaken) is that the Swift Foundation was created to address the principal concerns you've articulated. But ports have been slow: Linux works but with the previously mentioned lack of libraries, and there is a threadbare port to Windows which barely runs. The app I was working on was CLI-based that generated a log; and even for that non-UI use case, basic libraries we…
It's made quite clear every summer that Apple has a stranglehold on the language steering committee. When a new language feature that just so happen to enable a closed-source Apple framework drops out of the blue and then goes through a retroactive pseudo-open review.
Frankly, this distributed actors thing is more of the same -- it's something that someone at Apple thinks is important, so, despite it being just a library, it gets active support from the compiler and OS teams. There's absolutely no way that an outsider could have gotten anywhere proposing anything like this.
I like Apple's platforms and enjoy working with the language as well, but the openness is rather a charade.
Re: Swift Distributed Actors
#96Earlier quoted context omitted.
I’ve been using Swift to develop Apple software since 2014. I’ve released quite a few apps, written with it. Before that, I used ObjC. I’m extremely happy with Swift. As far as adoption goes, many large codebases are likely still ObjC; simply because of hysteresis. Major architectural shifts take a lot of time, money and risk. That’s one reason I don’t feel that much urgency to jump on the SwiftUI/Async stuff (but I…
To be clear, I quite like Swift and did from day 1. Granted I’ve only tinkered with it. What I didn’t like was interacting with Cocoa APIs. I found it difficult to use Swift’s protocols and structs in a FP style, because Cocoa isn’t designed that way. I imagine this has gotten a lot better since, particularly with stuff like Swift UI. That said, I’d personally find Swift more compelling to use as a server language.
Cocoa uses classic MVC, and actually started from NextStep (last century). UIKit smoothed it out a bit, but it’s still MVC/OO, under the hood.
SwiftUI was developed from the ground, up, to use FP concepts, and things like Protocol-Oriented Programming.
I’m looking forward to learning it, but the fact that most of the Apple world runs on tech from a design that was developed in the 1980s, should be an object lesson in the structural integrity of “classic” OO, and the MVC pattern.
We rubbish the past at our peril.
Re: Swift Distributed Actors
#97So 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.
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.
Re: Swift Distributed Actors
#98Earlier quoted context omitted.
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, a…
Erlang nailed the actor model.
Erlang incorporated some of the ideas of the Actor Abstraction
but missed a few things. See
See article and video here:
Re: Swift Distributed Actors
#99This 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.
Though it's nice to have so many choices, devs that really want actors will pick a battle-tested platform like Erlang+OTP in the 99% of cases. Because of the natue of BeamVM, which also got a JIT upgrade recently.
Also see offerings from Lightbend and Microsoft.
Re: Swift Distributed Actors
#100There 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…
In a Citadel, distributed Actors are going to be necessary.
See the following:
Citadels: faster response time and better information integration than remote datacenters