cocoaphony

cocoaphony, 4 days ago

@mattiem For a while, I had assumed that I would only have actors, MainActor classes (which are almost actors), and values. But I am finding myself more and more reaching for Sendable classes.

When I need a small amount of isolation with a mostly synchronous interface, a Mutex (OSAULock) in a Sendable class has been much more practical than an actor.

Actors shine when many of their methods are naturally async.

The merging of "async because slow" and "async for isolation" is a bit awkward.

cocoaphony, 4 days ago

@mattiem I'm finding this even in "greenfield" situations. Making everything async creates a lot of special cases you have to consider during startup. You must always handle the "I may never have a value for this" case. You have to design UI that deals with that gracefully. It's a lot of work, when the only reason you needed it was for thread-safety.

Consider a simple case of a SwiftUI View that has a configurable background color stored in an Actor. How do I display the View?

cocoaphony, 4 days ago

@mattiem If I want that value to be accessed from non-UI contexts (to bidirectionally sync with the server, for example), then I'm going to need isolation.

So the question is which side is "default?" Do I need to justify the actor because of its impact on the UI, or do I need to justify the Mutex because actors are the "right" tool for isolation?

"Mutex unless it's a fundamentally async service" or "Actor unless it breaks the UI?"

If SwiftUI were itself async, this might be different.

cocoaphony, 4 days ago

@helge @mattiem I think that's a different thing. Making Views not be MainActor IMO leaves open CALayer-style rendering loops, where multiple versions of the same layer are computed in parallel. The deep idea IMO of View is that it be purely a transform of fixed State to a renderable tree.

In practice, I don't know if this will be realizable. But I'm kind of hopeful that it could be.

By "SwiftUI is not async" I mean there's no AsyncView like AsyncImage that makes "loading" a first class state.

cocoaphony, 4 days ago

@helge @mattiem Here's a terrible implementation I use in a personal program that needs async-loading of views because computing them is slow. Yes, I use Text("loading") as the placeholder View. Developing something better is hard, and the kind of thing that async-first makes you grapple with in ways that are time consuming.

cocoaphony, 4 days ago

@helge @mattiem The trouble is there's no distinction between what we often think of as "fast async" (isolation) and "slow async" (I/O). Swift treats all async as "potentially slow," and forces us to grapple with the case that it never returns. "Loading" would have to exist because there might be network. But adjusting things to assume async is fast (i.e. allowing us to block synchronously on await) opens the door to hung programs.

That said, Swift does nothing to stop sync from being slow....

cocoaphony, 4 days ago

@helge @mattiem Ultimately, this is not unlike the idea I posted from Joe Armstrong. In truth, any lock (especially an unfair lock) can block forever, so in principle every access should deal with that.

This pedantry is a powerful tool for making our programs correct. It really has driven out many bugs from my code where the compiler caught things I thought were impossible, but are actually only rare.

This pedantry is also a powerful tool for driving programmers to throw things.

cocoaphony, 7 days ago

@jsq I’d been moving to “sign-in with Apple” on any site I could and the passkeys. And now I find myself looking for the link that lets me use email+password because it’s the only thing I trust to work 5 years from now with my 1Password7 vault that I will never, ever upgrade.

This is a very strange place to be as an early-adopter type. I made GPG keys! I helped build corporate PKI systems. I studied FIDO2 specs. But good grief. Why’d it have to go this way?

cocoaphony, 7 days ago

@dxzdb @jsq The move to 1Password 8 burned a lot of trust that AgileBits built up from the 1passwd days. I've finally been dragged to cloud storage, even on 7, so it's probably at this point as much personal history as specific technical issues. l always trusted AgileBits a great deal. I don't know if I have full trust in this company.

That said, I've been using 1Password7 for a long time and I know how it behaves. I need a pretty strong reason to risk breaking my autofills.

cocoaphony, 10 days ago

@davidbures I can't reproduce this. Posted some comments. How did you setup the directories and links?

cocoaphony, 12 days ago

@tonyarnold @rjmccall is there a reason for attaching this to a property rather than adding an Actor requirement to the protocol? (The alternate is generally to make things the conformance requires async, which might be the thing you’re running into rather than isolation.)

cocoaphony, 23 days ago

@mattiem @jsq Agreed. I'd rather just copy the couple of lines than turn it into a formal template.

cocoaphony, 23 days ago

@krzyzanowskim Not the linked one (that's what I'm moving to instead of moving the setting). This one: https://gist.github.com/rnapier/1bf7a85eea76dc76fc61ad6aa0808fd2

cocoaphony, 22 days ago

@krzyzanowskim see also https://mastodon.social/@NeoNacho/112408474518536814

cocoaphony, 24 days ago

@schwa It is the second-worst tool that I can't find anything better than and so use every day for just about everything.

The first is VSCode.

In both cases, they're really powerful and can kind of do everything, and any complaint can probably be fixed if I were willing to write code for a few hours (and then maintain that code....). But so many little annoying complaints....

cocoaphony, 29 days ago

@alexr @schwa What strikes me is how the same behavior lands so differently when trust and morale is high. Some of the most impactful bonuses I've ever received were $10 "Splash" awards that you could exchange for stupid stuff from a catalog. The branded lunch cooler I got 25 years ago I still have.

But they came with a hand-written note from a colleague. And morale was high. And the company was supportive. Splash awards were "and also your teammates can recognize you" rather than "instead of…"

cocoaphony, 1 month ago

@Jeehut from what you seem to be doing, you likely want a TaskGroup for your loop. Your other async-let look ok. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/concurrency/#Tasks-and-Task-Groups

cocoaphony, 1 month ago

@aleck @stroughtonsmith similar for me. The process of converting, which is still in its mid phases, has uncovered quite a few existing race conditions and threading violations, several of which have turned out to be the answer to existing crash reports.

Answer: it finds bugs.

The downside is it finds bugs you think you don’t care about, often related to debug tools or unit tests.

The upside is it’s uncovered bugs I didn’t think I cared about but were actually causing the unit tests to crash.

cocoaphony, 1 month ago

@helge @aleck @stroughtonsmith we’ve done almost no rewriting. I turn on targeted or complete, see what happens, turn it back down to minimal, and try to fix things it found. But the fixes are most commonly “make MainActor.”

The bugs are usually discovered because “make MainActor” creates errors in other places and when I try to fix them I discover that other place assumed it was not MainActor.

Plus it points me to places we were modifying properties on random threads.

cocoaphony, 1 month ago

@helge @aleck @stroughtonsmith it is fair to note that several of the bugs have been discovered just because it forced someone to go look at code that hadn’t been touched in a while, and then say “wait, that doesn’t look right.” And all kinds of things that forced us to just go read old code might have done that.

But quite a few have been specifically “mark MainActor, compiler complains, find existing mistake.”

cocoaphony, 1 month ago

@amonduin @helge @aleck @stroughtonsmith I think most of this can be summarized as "Swift Concurrency lacks a serial queue." Yeah. IMO, that's a glaring hole right now. There are pretty simple patterns that let you create one using a single Task var, and AsyncChannel allows very powerful Go-like constructions. But all the approaches are still kind of ad hoc and tricky to do perfectly. There is a "patterns cookbook" in the works, and I'm hopeful that means by WWDC.