Swift Evolution: Actors

https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md

by mpweiher • 5 years ago

264 155 5 years ago

github.com

DelightOne• 5 years ago

Currently active review: https://forums.swift.org/t/se-0306-actors/45734

Review by Chris Lattner: https://forums.swift.org/t/se-0306-actors/45734/4

gigatexal2• 5 years ago

Chris's review is really impressive. Anyone doing code review should take note.

macintux• 5 years ago

I agree: well-written, well-presented, well-considered.

(Of course I'm heavily biased against inheritance, but I think it's a very good review regardless.)

qaq3• 5 years ago

I really like how Swift is shaping up. They keep making choices that imho give you good balance of ergonomics and performance.

blacktriangle3• 5 years ago

I can't help but feel the opposite, as if Swift is a dog chasing cars. Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL. Some types showed that the whole protocol oriented programming model breaks down in some serious ways. And now they are looking at doing actors as a whole new built-in functionality rather than just a concurrency library. It looks like the Swift language is just too rigid and unable to evolve in useful ways without the blessing of the language developers themselves.

afavour• 5 years ago

I really enjoy working with Swift but after looking at this Actor proposal I think I agree with you. It seems like you'd always want to use actors? Unless you specifically don't want things to be concurrency safe. It feels like something the language should have had from the start or should have as an external library.

raspasov2• 5 years ago

Agree. Either choose to use lisp syntax and lisp macros or add all the language "features" ad-hoc one by one over the years.

ckok• 5 years ago

I can't help but get the feeling that plan with Swift is to be the only language you can effectively use for Apple platforms, but also is probably going to be the language that will only be used on Apple platforms because of Apple's whims like the function builders.

ragnese5• 5 years ago

Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL.

Ugh. I agree. I haven't actually used SwiftUI in anger yet, so I try to reserve my judgement, but the whole thing seems like a lot of magic and complexity to me (not to mention reports of some performance issues/gotchas).

Didn't they also add some weird dynamic JavaScripty property getters or something?

slavapestov4• 5 years ago

Some types showed that the whole protocol oriented programming model breaks down in some serious ways.

How so? Rust has an equivalent feature (impl Trait) for example. It solves a legitimate problem.

astrange8• 5 years ago

The point of doing concurrency as a language feature is that it can stop you from writing incorrect programs in a way that a library can't. Besides, Swift already has concurrency libraries because Objective-C did - dispatch, NSOperation, NSRunLoop and so on. The problem is it has too many of them.

skohan10• 5 years ago

Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL

I totally agree. It's actually a big part of the reason I pulled back from Swift development for personal projects, since it appears that the core team has no problem shoe-horning in half-baked features if it's required to make the necessary impact at the keynote of WWDC.

However I think that example (along with property wrappers) shouldn't be used to impugn the language design decisions as a whole. Protocol-oriented programming is extremely powerful in Swift, and since I have switched to mostly using Rust over the past year for personal projects, there are a lot of things about Swift I really miss.

ragnese5• 5 years ago

I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result.

As much as I actually do enjoy working with Swift (real type classes!!), there are some parts that are a big WTF.

slavapestov4• 5 years ago

they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result.

This is exactly what the new async/await feature solves though. Actors are built on top of that.

ogre_codes3• 5 years ago

I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks.

It is frustrating, but it seems like they are finally getting there. It’s frustrating since a language like Go had a good concurrency model almost from the start. But Go had different constraints and arguably has less surface area to cover.

Nican• 5 years ago

Oh! Actors is one of my favorite paradigms of lately. I have been reading plenty about Akka as well.

When I start looking into the subject further, I start falling into a rabbit hole of how Actors are sometimes treated as a database, that is hard to query, and provides no transaction-ability across actors. There is some argument that Actors could be reimplemented using Postgres' "SELECT ... FOR UPDATE", since you can lock the row for the duration of the transaction.

Anyone else have experience managing large amounts of data inside of Actors have a say about this?

halfmatthalfcat• 5 years ago

I use Akka extensively and have not heard (and would never) use Actors in that capacity.

dmux• 5 years ago

You have to walk a fine line with Akka IMHO. Having inherited and supported an Akka Cluster for 4+ years, I'd strongly recommend that you evaluate whether you really need an Actor based system or if a plain-old set of services talking to each other via a message-broker would suffice.

The particular system my team inherited gave us nothing but issues: cluster coordination issues, so quorum wasn't met and things wouldn't start cleanly, network partitioning issues so nodes would randomly be considered dead, actors "becoming" (the term used IIRC) other types of actors based on messages received... the whole thing was just.. too ephemeral and organic for our tastes. I used to get excited thinking about systems like that, but I've since grown more conservative in my technology / architectural preferences (i.e. choose boring technology). We actually ended up replacing it with exactly what I suggested: a plain-old set of services talking via a message-broker. It's stupid simple and we've all slept better.

Edit: I will say that the use of actors constrained to a single service to handle concurrency is probably way more supportable than in a clustered mode.

fearthetelomere5• 5 years ago

With something like Elixir/Erlang, the distributed system is quite robust and reliable from my experience. A bit rigid and somewhat difficult to configure for custom topologies, but dependable overall.

a plain-old set of services talking via a message-broker

That said, I think you're absolutely right with distributed Akka. I'm very hesitant to fully embrace it, and we use simple service-level APIs to communicate between nodes. I understand the developers have made a lot of progress on the functionality of remote Akka over the years, but it's just not as tried and true as I would like. Using Aeron for message transport for example, is something that may be the best tool available, but is really hard to sell to my org when simple services are more approachable and maintainable.

actors "becoming" (the term used IIRC) other types of actors based on messages received

Yeah... I didn't understand why my org was using the Classic Akka instead of the new and improved Typed Akka for a long time. But cool-looking things like this just aren't worth it sometimes. Especially when Classic Akka "just works".

kag0• 5 years ago

I don't have experience with managing large amounts of data with actors. But I can say from the actor experience I do have that you can't think about it in the mindset of "how can I replace my relational database with actors".

Actors can be a near-sliver bullet for some things, but you have to think about solutions differently. I always though a bank was a good example. One actor per-account, how do you think about money in flight and such? Probably in a fundamentally different way than you would in postgres.

hard to query

That one is easy though, CQRS

wrren• 5 years ago

Over a long enough timeline, all languages converge on the Erlang feature set!

skohan10• 5 years ago

Erlang has an incredibly compelling value proposition! The problem is that the tooling and ecosystem are not really there. I tried to dip my toe into it maybe a year ago, and the error messages have not held up according to modern standards.

fredrikholm• 5 years ago

Have you tried Elixir? It's a thin language wrapped over Erlang, filling in the holes of the areas you mentioned, and was designed for exactly that purpose (programmer ergonomics).

the_duke• 5 years ago

I love actors, but baking them into the language like this seems like the wrong approach to me.

The language should provide all the necessary abstractions to create an isolated context. Actors can then "just" be a default abstraction provided by the standard library.

Side note: has the Swift cross platform support improved? I was very much looking forward to using Swift as a general purpose language, but Apple didn't seem very interested in making it a true first class cross platform language. I believe IBM also dropped their "Swift for the server" efforts a while ago due to similar concerns.

EdwinLarkin• 5 years ago

Yeah.I would say the Swift ecosystem is too detached from different platforms than iOS/macOS.

It's a nice language but useless if you want to use it as a generic purpose tool.

wealthyyy• 5 years ago

Jony Ive - Introducing Swift Actors .......

Grustaf• 5 years ago

Then it's lucky that 1 billion people use those OS:es. The wealthiest 1 billion at that...

skohan10• 5 years ago

I think "useless" is way too strong here. Swift doesn't have the same community support outside of Apple platforms as something like Rust and Go, but it's a very capable general purpose language with plenty of platform-agnostic packages available if you look for them. Also the C interop is great, so you have access to the last 50 years of prior art.

I think the argument is vastly overstated that Swift is not useful without Apple frameworks. It's similar to C# - you have the language, and then you have Windows APIs. Nobody would argue that C# is "useless" outside of Windows.

machineko• 5 years ago

Its okish on ubuntu and wsl but windows still lag hard. Worst think is very narrowed libaries working only on apple devices even most cool open source projects are just locked and are looking only on apple ecosystem (dont get me wrong its huge enough to just ignore other ecosystem at the moment sadly)

Someone• 5 years ago

“has the Swift cross platform support improved?”

That’s hard to answer without a “since when”, but the answer probably is “yes”. See https://swift.org/platform-support. There are Windows binaries now, for example.

Many of Apple’s libraries aren’t available on non-Apple platforms, though, so many would say it hasn’t improved enough to be competitive with other languages.

drmidnight5• 5 years ago

While it takes some work I have successfully run Swift code on the usual suspects (iOS/Mac) as well as Windows, Android and Linux.

If you ditch Foundation and rely on C libs you are able to use it pretty much anywhere.

anonymouse0082• 5 years ago

What are you using for GUI libraries? Or are these mostly accessed from the command line?

In my own experimentation, I’ve seen some success with Vapor 4 and PlotHTML

bsaul3• 5 years ago

i'd be EXTREMELY interested in knowing more about that. I'm currently developing an app on iOS in swift, in the hope of porting the model layer to other platforms such as android (i don't mind redevelopping the UI).

i have been carefully avoiding any objective-c code so far, but i must admit i haven't been to careful with foundation dependencies.

Do you have a blog post explaining what you did and what limitations you encountered ?

staplung• 5 years ago

The "official" Swift LSP was begun in 2018 but there doesn't seem to be much going on there these days. The readme still says "SourceKit-LSP is still in early development, so you may run into rough edges with any of the features." That hasn't changed since the first commit. I can't help but feel that part of the problem is that the language is too complicated.

liuliu2• 5 years ago

sourcekit-lsp is actually pretty light-weight implementation as it shares the same sourcekit code with Xcode. VSCode's sourcekit-lsp integration is OK to me.

The only issue for me is that I don't use Swift Package Manager, hence, the build system (Bazel) integration is simply not there (the BSP support from sourcekit-lsp is dead).

saagarjha• 5 years ago

sourcekit-lsp ships with Xcode and has gotten much better. The first release would hang for minutes the moment you imported Foundation; these days it doesn't really hurt performance at all. (I use it in Sublime Text, FWIW.)

rozap• 5 years ago

but..the "provide all the necessary abstractions to create an isolated context" is the hard part. It trickles into every part of execution. How do you do isolated contexts without saying any process can be preempted at any moment? How do you isolate things when there's shared memory? To do this right you end up with something like Erlang which makes a lot of sacrifices in order to get there, though you have a fighting chance at dealing with concurrency. And if you bolt it on to the runtime without those pieces in place you end up with something like Akka which has tons of gotchas and ends up being way more confusing than just programming the way the JVM wants you to.

it seems like these fundamentals are in tension, and tradeoffs need to be made, which just means that there won't be a one size fits all paradigm. maybe someone will create something that is truly magic and does everything, but more likely they're trying to sell you something.

slavapestov4• 5 years ago

There are also the various static checks that prevent you from accessing actor-isolated state outside the actor, or passing non-Sendable state across actor boundaries. It's not clear how a general language extension mechanism could implement those.

infogulch• 5 years ago

It seems like the problems of memory ownership and the first simple solution to it -- borrowing -- are fundamental to computing architecture.

zamalek• 5 years ago

How do you isolate things when there's shared memory?

That's precisely what actors aim to solve. Actors pass messages, not memory.

Akka

If you look at an actor framework built in a feature-rich language (Orleans), that problem isn't apparent at all. Even Rust, with all the ownership complexity, manages to do elegantly handle actors, without an explicit plan to do so. Your critique is more relevant to Java than actor libraries.

favorited• 5 years ago

I have some personal Swift-on-the-server projects deployed in "production" (as in, I use them every day, but I'm the only user) and it works great for me. They're running in Docker containers deployed to Heroku; there might be better ways to deploy it, but I'm not a backend engineer anymore so this is as much as I knew how to do.

I haven't tried it on Windows yet, but I know that it is officially supported now.

eternalban• 5 years ago

The language should provide all the necessary abstractions to create an isolated context. Actors can then "just" be a default abstraction provided by the standard library.

A stated goal is static, compile time, prevention of concurrency error. You can't do that with a concurrency library unless you restrict yourself to purely deterministic code.

jayd163• 5 years ago

I was going to agree but looking at the proposal I don't.

"Actor" in this case is more like a new access modifier than another type.

I don't see how you could really do this in a standard library as cleanly.

jojobas• 5 years ago

Why would anyone want Swift on other platforms?

From the start it seemed to be mostly a product of NIH and the necessity to move away from Objective C while keeping some compatibility. Other platforms tend to allow you much better choices.

drmidnight5• 5 years ago

Personally I find it to be a nice blend of language features that I really enjoy. It's expressive and readable.

If you can find a language that you actually like to work in then why not use it on other platforms?

The dependencies really come down to the Apple frameworks. Ditch those and it's no different than any other general purpose language.

kevbin• 5 years ago

Why would anyone want Swift on other platforms?

Myriad reasons. If—for whatever reason—someone likes to program in Swift, having high-quality implementations available on various platforms is a win.

Other platforms tend to allow you much better choices.

This assumes an objective measure of programming language goodness. Whether a language is better than Swift is an opinion. Opinions vary.

user-the-name• 5 years ago

I have not seen any "much better choice". Swift is one of the best languages I have ever used on any platform.

eyelidlessness2• 5 years ago

baking them into the language like this seems like the wrong approach to me

Wasn’t it baked into Erlang (well, OTP, but like there’s a distinction), where the model originated?

Ndymium• 5 years ago

The actor model didn't originate in Erlang and AFAIK the developers of Erlang only accidentally implemented it, learning of it later. Wikipedia[1] has history of the actor model from the 70s when Erlang was developed in the 80s.

[1] https://en.wikipedia.org/wiki/History_of_the_Actor_model

dwaite7• 5 years ago

Side note: has the Swift cross platform support improved? I was very much looking forward to using Swift as a general purpose language, but Apple didn't seem very interested in making it a true first class cross platform language. I believe IBM also dropped their "Swift for the server" efforts a while ago due to similar concerns.

The reality is that the ability for this to happen _always_ depends on the motivation of parties to make it happen. With a proprietary language/compiler, you are at the mercy of the owner while with open source you can contribute the changes - but in either case you can't will other parties to see the business value and do the work for you.

There are still first-party projects to help with Swift on the Server (which is necessarily cross-platform), swift has official containers on docker hub, there is and Apple does contribute to these efforts. X86 Ubuntu, Centos and Amazon Linux are part of Apple's official CI, while the community contributes CI for various other chip architectures, Android, and Windows.

However, the bulk of Apple's investment in Swift is obviously in their own interests - just like any other open source contributor. IBM and Google both stopped contributing officially, but from what I've seen it appears that has more slowed community work than stopped it.

skohan10• 5 years ago

I think part of the issue here is that Swift is radically more difficult to compile compared with other languages. At least the last time I checked, which was several years ago, Swift was using a number of slightly-modified versions of libraries compared to what you would get from a standard package manager, so setting up the environment to compile swiftc on an arbitrary Linux distro was no easy task.

dwaite7• 5 years ago

In addition to broader abstractions making code more readable and providing developers with less footguns in getting the isolation wrong, it also gives the compiler more opportunity to both default to safety (such as with structured concurrency proposal) and optimize protection and object allocation/retention patterns.

alexashka2• 5 years ago

This seems to be a way to tackle concurrency, without addressing distributed programming.

Why?

As far as I can tell, both Erlang and Akka (the two cited examples that implement actors) do both concurrent and distributed systems.

ex3ndr• 5 years ago

Because distributed part is library not language feature?

pjmlp3• 5 years ago

Erlang, Axum, Agent Tcl, Active Oberon are just a few examples where it is a language feature.

fearthetelomere5• 5 years ago

Actors aren't just about local concurrency, and if a language is attempting to bake them in, they should leave some room for the distributed case in my opinion.

One of the biggest benefits of using actors is that whether an actor exists on the same machine or across the network can be abstracted away from you. You're just sending messages, so you can send a message over the wire and it would be as simple to the developer as sending it locally. Not considering this use case would make it a very limiting language feature.

alexashka2• 5 years ago

Have they tried and found this to be the optimal case? If so, those findings should be part of the proposal if it were up to me.

Distributed programming is not a little add-on you can slap on top of a non-distributed system if history has taught us anything.

bsaul3• 5 years ago

That was my first reaction as well when i saw the way swift team was laying out the roadmap to actors. The broke all what we consider an "actor system" into pieces, and implemented every part in different, hopefully orthogonal, proposals..

If that works it's going to be quite interesting. But i feel that it goes against what i've learned from go language design decisions : concurrency is such a deep concern that you have to build the whole language around it, as well as from erlang, where they basically designed the virtual machine around the actor requirements.

It's going to be some interesting times..

astrange8• 5 years ago

How would you want to address it?

There is already a distributed programming library on the system called XPC, so people already have experience with it, but you certainly can't program as if every method call might become remote. Mainly the problem is every call can fail, and sometimes retrying is correct and sometimes it isn't, but also the costs of passing a large function parameter become different cross-process and then more different cross-machine.

Note ObjC already had some language features for an older library (DO) like 'inout' parameters, but they were actually removed because XPC instead only uses callbacks.

mrkeen• 5 years ago

we can implement a correct version of transfer(amount:to:)

    // Safe: this operation is the only one that has access to the actor's isolated
    // state right now, and there have not been any suspension points between
    // the place where we checked for sufficient funds and here.
    balance = balance - amount
    
    // Safe: the deposit operation is placed in the `other` actor's mailbox; when
    // that actor retrieves the operation from its mailbox to execute it, the
    // other account's balance will get updated.
    await other.deposit(amount: amount)

Am I correct in thinking that the system temporarily destroys money here (and hopes to recreate it if the receiver doesn't crash?)

If I have a closed system of actors constantly transferring money among themselves, and I poll to see the total amount of money in the system, will it fluctuate?

liuliu2• 5 years ago

I think that you are correct. There is a paragraph on actor's reentrancy: https://github.com/apple/swift-evolution/blob/main/proposals... which points out that you can definitely get balance before await, therefore, have fluctuated total.

rkalla• 5 years ago

In the code above it certainly looks like that - is this not idiomatic swift-finance code though?

syrrim• 5 years ago

They say that the `deposit` call is placed in `other`s mailbox. As long as the mailbox is preserved between restarts, then there is no danger of the money disappearing. The money will temporarily be unavailable - that is, in neither account's balance. But the money is still somewhere, in the mailbox.

gpderetta2• 5 years ago

A crash between updating balance and putting the message in the mailbox can still result in an inconsistent state.

msoad• 5 years ago

There is also Swift Atomics[1] that is probably needed here

[1] https://swift.org/blog/swift-atomics/

ogre_codes3• 5 years ago

I was thinking the same thing as I read this. Keep in mind, these examples are meant to illustrate how Actors work, not how to write good banking code.

centimeter• 5 years ago

This is an especially poor choice of example given that it's the canonical example for STM, and STM actually solves the problem.

jayd163• 5 years ago

You're assuming you can read balance in a dirty way, but it seems like you would call an async GetBalance() method that could not read the value of balance until transfer has fully completed.

Any experts that can confirm this?

helge9210• 5 years ago

TLDR: account balance is not a good example to simply explain actors.

Actor model in general doesn't guarantee the ordering of the messages.

The is possibility that all the withdraw messages arrive first and all the deposits later.

Balance poll result makes sense only with assumption "all messages before this point of time have been processed"

blt• 5 years ago

The idea of the "mailbox" reminds me of Dispatcher.BeginInvoke in C# on Windows. It is very powerful, but can also lead to messy code where many threads are mutating shared state and failing to fully reason about all the other mutations that can happen.

Systems with explicit communication, i.e. based on queues, encourage the programmer to limit the number of possible ways in which worker threads can interact with the thread that manages mutable state. They also require something like a big switch statement where all possible interactions are listed in one place. It seems like in actor-based code, all the possible interactions with the mutable state could be spread across the code base.

On the other hand, these hand-written message loops and switch statements are essentially the same code that the compiler would generate for an actor's mailbox processing loop. One could argue that writing them by hand is a waste of effort. Programmers simply need to use discipline. (Similar to virtual dispatch in C++, for example.)

I am curious about the opinions of programmers more familiar with concurrent architectures. Does the actor model make it easy to write concurrent spaghetti code?

fearthetelomere5• 5 years ago

Does the actor model make it easy to write concurrent spaghetti code?

I think you could write concurrent spaghetti code in any environment just as easily, to be honest. I also think it really depends on which actor-model implementation you're using. Each offers their own unique experience, as I've found that there's a noticeable difference in the Scala+Akka approach vs Elixir+OTP, for example.

The actor model is just one way of reasoning about concurrency. Your mailbox serializes/linearizes your interactions so you don't necessarily need locks. Because you get that for free, you can write "single-threaded" code to handle each message. Messages can be sent across a network, so now you can concurrently interact with remote actors too. The simplicity of the model stops there.

Concurrent code gets complicated very quickly by nature. If you architect your application to have messages causing ripple effects in your system, your application behavior is going to be very difficult to reason about. But that's nothing new, either. Instead of sending messages, concurrent function calls could produce the same issue.

Is reasoning about message flows and behaviors hard? Yes, but that's just a byproduct of concurrency. Like you said, "programmers simply need to use discipline", but everyone will disagree on what discipline looks like. Each actor model implementation will have their "best practices" to mitigate the complexity of concurrent interactions, as will each organization using said implementation for their project. At my work, the way we use Scala+Akka was very structured and not at all the way I expected, having been used to Elixir+OTP.

As I think the issues of the actor model are actually issues with reasoning about concurrency in general, I would pick actors over coroutines just for the up-front structure and simplicity it provides.

toast02• 5 years ago

Is reasoning about message flows and behaviors hard? Yes, but that's just a byproduct of concurrency.

Maybe it's just me, but message flows and behavior is a lot easier to think about than concurrent access to shared state.

In an Erlang world, it's fairly easy to look at a process's code and see what it does for each message it might get, and think about if it's correct or not. Of course, it's sometimes hard to see which messages it might get from other code; also the system behavior can be a challenge to understand at times, although generally going back to making sure each actor does the right thing, and making sure the right number are running gets you most of the way there.

With the re-entrant Swift actors proposed in the link, I'm not so sure it will be easy. It looks like if your actor A's method needs to call another actor and read the response, that opens actor A to running other methods between the call and response; that makes it hard to think about again.

pixel_tracing• 5 years ago

I really don’t like that we have the overhead of a new keyword called actor

kyberias• 5 years ago

What kind of overhead do you think a keyword could bring?

ardit33• 5 years ago

it is called language verbosity... over time it ads up and creates a difficult language to work with, and hard for beginners to start with

xiaodai• 5 years ago

Will it go the way of AD in Swift or Tensorflow for Swift. Maybe not coanit might fit in the Swift ecosystem

danappelxx• 5 years ago

From what I can tell UIKit and friends will adopt this actors eventually via bridging (just like they adopted Swift 3's error handling).

zepto4• 5 years ago

No, because that was a fork, and this is mainline development.

waffletower• 5 years ago

Investment in STM (Software Transactional Memory) through implementation of supporting data structures, could be a more effective investment for this problem space.

fiddlerwoaroof• 5 years ago

Clojure’s STM is basically unused: from what I can tell, STM turns out to be better in theory than in practice.

lilactown• 5 years ago

The problem IMHO is that there aren't a lot of problems that are particularly suited to STM.

I can't think of many instances where I would use STM over CAS (e.g. an atom in Clojure); and the times I have needed something akin to STM (e.g. building an incremental dataflow engine with transactions) I wanted more control over the runtime behavior than Clojure's STM provided.

Plenty of business systems need transactional guarantees and either durability or distribution (or both), which makes an external store like Postgres or Redis a ton more attractive than STM within a single process.

astrange8• 5 years ago

I don't think image computing is a good idea and so I don't think complicated memory updating abstractions like this are necessary.

The other problem is that Intel tried to add STM to their hardware, but it has so many bugs that it's been disabled in multiple CPU generations. I only know one program that uses it and it's a PS3 emulator, not a database.

layoutIfNeeded2• 5 years ago

Another thing that’s about to be bolted onto Swift at the language level (instead of making it a library). Sad!

slavapestov4• 5 years ago

You'll need to explain how the static isolation checking could be feasibly implemented in a library.

layoutIfNeeded2• 5 years ago

This is not gonna end well: https://tclementdev.com/posts/what_went_wrong_with_the_libdi...

bsaul3• 5 years ago

No idea why you got downvoted. The fact that the first implementation of the actor system is most certainly going to be on top of libdispatch makes it a very interesting property. Libdispatch is really not known for being able to spawn thousands of "light thread". And so there is indeed a potential pitfall in making asynchronous + concurrent code easier.

However, after having read a lot of the swift proposal relative to concurrency, i am still unsure if the end result of production code is going to be lots of actors running in parallel, or just lots of async calls multiplexed on a few OS threads.

astrange8• 5 years ago

You can easily have thousands of tasks (blocks) in dispatch, and thousands of queues as long as they're targeted to the same base queue.

The issue with dispatch is that it wasn't communicated enough that you want to have a few base queues and then a tree of other serial queues on top of that, so people end up running too many CPU threads at once, on a device that often has less than one core free at a time.

astrange8• 5 years ago

This post is a somewhat inaccurate rewording of official advice from the dispatch team at Apple, but that's one of the teams working on Swift concurrency so, like, it'll be fine.

viktorcode2• 5 years ago

lidbdispatch is a concrete implementation of a scheduler on OS threads. Actors (and new async model in Swift) are abstractions that are independent of underlying concurrency implementation. So the presumption that the new asynchronous model will inescapable have threads overhead is wrong.

toddh• 5 years ago

Once you have actors it helps to have a priority mechanism, latency guarantees, a scheduling abstraction so work can be partitioned, some sort of boost mechanism to prevent starvation, a timer abstraction, and a state machine abstraction to carry out work flows.

astrange8• 5 years ago

Swift concurrency has that in other reviews. Although not "guarantees" since it doesn't define a realtime system.

javajosh• 5 years ago

I find it hard to accept that a real actor model can be implemented at compile time!

machiaweliczny• 5 years ago

Whar do you mean by that?

jayd163• 5 years ago

At first I assumed this would lock all touched state across all touched actors such that you get the same kind of cross table-row locking guarantees a SQL call would give you

...but it seems like its still an open question in the RFC?

dwaite7• 5 years ago

actor state is meant to be read and modified only by the actor itself, which operates off of its own message mailbox (e.g. event queue).

I would expect actors to operate on their own state and on immutable data, and things such as transactional data coordination to be separate.

That said, I don't have nearly the experience with actors as many on HN - are you thinking of a particular actor-based system w.r.t touched state?

29athrowaway• 5 years ago

I thought the proper way to implement something like this was:

- fixed point instead of floating point numbers for currency.

- have a journal with transactions such as withdrawals and deposits, plus a "checkpoint" at one point in time where you store the computed balance.

e.g.: your balance is = starting balance for today + today withdrawals + today deposits

travisgriggs• 5 years ago

I like Actors. I have played with them in both Pony and Elixir. They were always an obvious next step from Smalltalk style everything-is-a-fricking-message oriented programming/thinking.

Is it just me, or is Swift getting really complex? As I read through Lattners evaluation, I found myself wondering "hadn't heard of that @Thing yet. I wonder how many there are that I don't know about."

Wile I was impressed about some of the nuance that goes into the combinatorial complexity of the many design patterns Swift wants to capture under its broad umbrella to make it a language for everyone, I kind of have to accept that I will probably never have the bandwidth to acquire the High Priest level of knowledge to really get the thing. Which means the odds of ending up with unexpected and surprising behavior actually rise. I feel more and more this way about Kotlin, Rust, and even Python these days.

Reading/writing code in these increasingly multi-paradigm ecosystems is starting to feel like reading epic poetry (e.g. Dante or Beowulf), but where different sections are written in different languages, with different prose and rhyming styles, some pieces a mix of two left for the reader to figure out.

I used to stress about getting these systems enough to code idiomatically in them, to use them "right." But more and more, I'm finding myself developing personal dietary menus in each, where I pick a nutritious subset that I can wrangle into some sort of expressive consistency, and just write code in that subset, idiomatic-fling-of-the-season be damned.

skohan10• 5 years ago

My experience with Swift was that there was a section of the language API that I used heavily, then I had features I would use every now and then, and others I would use almost never (like keypaths). I think one of the advantages of a multi-paradigm language is that you have the freedom to carve out a sub-language which is appropriate for a given problem or for your personal taste.

That said, I think Swift does sometimes feel like it's missing a metaprogramming system. Like property wrappers and function builders could probably be generated by a sufficiently powerful macro system, but instead they exist as one-off features with significant complexity.

dwaite7• 5 years ago

Is it just me, or is Swift getting really complex? As I read through Lattners evaluation, I found myself wondering "hadn't heard of that @Thing yet. I wonder how many there are that I don't know about."

Probably a fair few, although I wouldn't blame you for not knowing about something like @Sendable - since that is closely associated with the actor proposal.

sai_c2• 5 years ago

Every time I read about new Swift features, I'm reminded of this paragraph from Aaron Hillegass's book "Cocoa Programming for Mac OS X". I don't know why.

    Once upon a time, there was a company called Taligent, which was created by IBM and Apple to develop a set of    
    tools and libraries like Cocoa. About the time Taligent reached the peak of its mindshare, I met one of its 
    engineers at a trade show. I asked him to create a simple application for me: A window would appear with a  
    button, and when the button was clicked, the words "Hello, World!" would appear in a text field. The engineer 
    created a project and started subclassing madly: subclassing the window and the button and the event handler. 
    Then he started generating code: dozens of lines to get the button and the text field onto the window. After 45 
    minutes, I had to leave. The app still did not work. That day, I knew that the company was doomed. A couple of years   
    later,Taligent quietly closed its doors forever.

pindab0ter• 5 years ago

It’s a funny excerpt, but I don’t see how it’s relevant to this. It seems to me that the whole point of introducing actors is to reduce complexity.

sai_c2• 5 years ago

As I said, I really can't put my finger on it, but maybe it is this (tongue in cheek).

    Taligent: The whole point of adding all those abstractions is to reduce complexity.

midgetjones• 5 years ago

The main moral of this story is that people like to claim hindsight for some sort of psychic power.

BakaRakuda• 5 years ago

You can literally create the app described in his quote in about 2 minutes flat with the following lines of code...

  import SwiftUI

  @main
  struct FooApp: App {
 @State private var isClicked: Bool = false
 var body: some Scene {
  WindowGroup {
   VStack {
    Button("Click me!") { isClicked.toggle() }
    if isClicked { Text("Hello, World!") }
   }.frame(width: 640, height: 480)
  }
 }
  }

skohan10• 5 years ago

Even in the objc-cocoa days, you could create a .xib, drag a few connections, and have this working with 10 lines of code (8 of which generated automatically by XCode)

alfonsodev• 5 years ago

Remember Swift is also used in the backend and other areas that are not UI, not every new feature in Swift will be oriented to make UI apps easier, for that you have Swift UI the framework.

We don't get this type public proposals for Swift UI, I wish Swift UI would be open source, because the documentation hasn't been great in my experience and at least this type of proposals get publicly documented and discussed before being implemented.

bigbizisverywyz• 5 years ago

Funnily enough I just recalled this quote recently when casually looking over this page about WinUI3 : https://docs.microsoft.com/en-us/windows/apps/winui/winui3/x...

The whole XAML/WPF thing just seem to me a bit of a dig's dinner.

sriku2• 5 years ago

(some thoughts)

The "actor properties can only be accessed via self." constraint seems a very elegant and simple static expression that is understandable in a program. Love it.

On top of that, the rest of the proposal appears to stick to "message passing is method invocation" way of thinking about objects and therefore syntactically both get mixed up. I have a hunch that the language would be better off being explicit about message passing and keep it separate from "invoke an async method". (The proposal requires automatic conversion to message passing when it sees an async method invocation on an actor.)

The "access immutable properties directly" facility should reduce a lot of boilerplate that would otherwise crop up, but actor usage itself should stay away from styles that require such cross-actor access (opinion).

ivanbakel• 5 years ago

I have a hunch that the language would be better off being explicit about message passing and keep it separate from "invoke an async method".

What would be the benefit of this? (I haven't read the proposal in detail, but) If you can invoke an async method of an actor, it still has to be run in serial with the execution of messages to avoid races.

Besides, in the implementation I doubt that "messages" will be anything more than delayed async methods (and the implementation notes seem to support this). Actual actor systems rarely treat messages as first-class serializable entities - unless they hope to execute across multiple machines.

sriku2• 5 years ago

You're right on both counts. The mechanism of implementation will be very close .. which is what is in the proposal too.

Having programmed in Erlang, I feel that the notation (i.e. syntax) influences moment to moment thinking. So if there is overlapping notation between method invocation and message passing, I expect increased opportunity to code and design incorrectly, resulting in subtle bugs.

Making "async message passing" syntactically explicit and obivous clarifies a lot and prevents expectations of calling other methods, facing compiler errors, or worse having to deal with specified behaviours that may not be what I had in mind.

Edit: one example of this confusion in the spec is the whole part about inheritance in actors ... which looks like a terrible idea to me.

legulere• 5 years ago

awaits in actor-isolated functions being reentrant seems like a huge opportunity for bugs, because it is not obvious at all:

https://github.com/apple/swift-evolution/blob/main/proposals...

Swift Evolution: Actors

Related Stories