Swift Distributed Actors

> I don’t think this is nefarious. X11 is a klunky GUI, at best,

That's the problem: I see you're being dismissive of X due to its ergonomics and aesthetics despite the fact that X just-works and is still a vital component in computing: the same reason Windows retains both cmd.exe and PowerShell - I feel that your kind of reasoning is why we think Apple is so capricious with their consumer products (removing iPhone headphone ports, deliberately making HomePod incompatible with Android and non-Apple Bluetooth devices, the Trash-can MacPro, etc) they're roistering their own kind of paternalistic computing vision on their users).

People that need reliable, dependable computing experiences need to be able to use all the tools out there: old-but-good, tried-and-tested, no matter how "clunky" they are - and this doesn't neatly fit into the Apple way(TM). While I appreciate and respect Apple immensely for significantly and successfully driving the standards for user-experience and overall product industrial design, it isn't perfect... if only they'd tone-down their institutionalist corporate arrogance.

> compared with pretty much everything else out there. It really can’t hold a candle to more developed GUI systems.

X is a windowing system, it isn't a complete GUI system. Consider that, in fact, what Apple and Microsoft have both done quite successfully since the very beginning of macOS and MS Windows is how they have completely hidden the fact that widget/control libraries, the window-manger, the windowing-system, the compositor, are all completely separate and independent components that actually have no dependencies on each other at all. Having that visual and design consistency between those functionally separate components is what made Windows 95, and MacOS 8 (and especially OS X) so usable and approachable to _normal people_.

Now as X and Wayland are just one component in an entire GUI system, there really isn't a strong argument in removing vital components from their own systems just because they just don't like the way it looks - as though Apple is trying to avoid looking like a HP-UX CDE desktop from the mid-1990s.

I'm rambling, it's 3am now argh.

Is it Apple’s responsibility to maintain X on the Mac, though?

If they want to implement something that may interfere with X (usually they do this kind of thing because security), should they cripple the experience for half a billion users, to appease a small minority of techies?

I’ve been writing software for Apple devices since 1986, which means that I’ve had lots of rugs pulled out from under me, and have been incandescent with rage at Apple, many times.

That said, I’ve never regretted choosing it as my preferred platform, despite thirty years of insults and put-downs from other tech folks.

You are describing Erlang and it can not get simpler than that.

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.7...

[2]: http://www.cs.yale.edu/homes/aspnes/classes/465/notes.pdf

Java RMI was based on Objective-C distributed objects ideas actually, so it is no wonder that these things kind of go in circles.