3 ms·

Do you try to put everything on the main actor to dramatically reduce your debugging time?

hn-acct 1y ago
Everything probably already is or should be
trevor-e 1y ago
Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.
- favorited 1y ago
  Especially in apps, where most of the code will be about preparing the user interface and handling events. And it's relatively easy to make most lower-level components actor-agnostic – either by making them conform to Sendable, by making them actors, or by giving them their own internal synchronization.
klabb3 1y ago
I can’t speak to swift, but in experience with many other langs and runtimes I will say that single-threaded business logic by default is still the only sane choice even today. There are exceptions both on client and server side, but you get so incredibly far with one thread, while eliminating so many potential bugs, that it’s borderline whether parallelism should even be exposed to application developers at all. Even in Go which has my favorite parallel concurrency model, there are many footguns and needless walking on eggshells for business logic. You can still offload IO and bespoke compute to other threads when it makes sense. This view isn’t a panacea, but damn close for the 99% of use cases. Coincidentally I also think the early success of JavaScript an largely be attributed to single-threaded run-loop and callback-oriented concurrency. Even on the server JS is still holding strong with this limitation, and that’s despite all the other limitations and insanity of JS.
- monkeyelite 1y ago
  Absolutely - the idea of threads haphazardly interacting, like 2002 Java, is a terrible default assumption for designing languages and libraries. It's not even clear the perf gains are great. Everything locking all the time has killed a lot of performance.
Hashex129542 1y ago
Apple effectively solves the problem which doesn't exists. Before Swift 6, I've worked lot of unique projects both macOS and iOS and never spend time on debugging. I don't know what debugging time exactly?

Everything probably already is or should be

Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.

favorited 1y ago
Especially in apps, where most of the code will be about preparing the user interface and handling events. And it's relatively easy to make most lower-level components actor-agnostic – either by making them conform to Sendable, by making them actors, or by giving them their own internal synchronization.

klabb3 1y ago

I can’t speak to swift, but in experience with many other langs and runtimes I will say that single-threaded business logic by default is still the only sane choice even today. There are exceptions both on client and server side, but you get so incredibly far with one thread, while eliminating so many potential bugs, that it’s borderline whether parallelism should even be exposed to application developers at all. Even in Go which has my favorite parallel concurrency model, there are many footguns and needless walking on eggshells for business logic. You can still offload IO and bespoke compute to other threads when it makes sense. This view isn’t a panacea, but damn close for the 99% of use cases. Coincidentally I also think the early success of JavaScript an largely be attributed to single-threaded run-loop and callback-oriented concurrency. Even on the server JS is still holding strong with this limitation, and that’s despite all the other limitations and insanity of JS.

monkeyelite 1y ago
Absolutely - the idea of threads haphazardly interacting, like 2002 Java, is a terrible default assumption for designing languages and libraries. It's not even clear the perf gains are great. Everything locking all the time has killed a lot of performance.

Hashex129542 1y ago

Apple effectively solves the problem which doesn't exists. Before Swift 6, I've worked lot of unique projects both macOS and iOS and never spend time on debugging. I don't know what debugging time exactly?