undefined | Better HN

0 pointseaurouge3mo ago0 comments

The point I was trying to make is that you can apply the actor model to any system of isolated processes. Whether the isolated processes live on a distributed system of networked computers or on the same computer is an implementation detail. The critical issue is that each actor should own and mutate its own state. Whether all actors run on the same thread or on separate threads is also an implementation detail. For instance, AtomVM is a lightweight implementation of the Beam (actor model) that runs on microcontrollers [0].

> The entire thrust of this thread is that you can have a more reliable system that is easier to reason about if you use specific constructs that each have less power

Easier to reason about, sure, fine. Your earlier comment claims the actor model is a dead end in non-distributed systems.

> Unstructured concurrency should be reserved exclusively for contexts where structured concurrency is impossible, which is what the actor model is for.

Results from my quick search on structured/unstructured concurrency were all references to Swift. Is this a Swift thing? In any case, the issue appears to be more about managing tasks that don't require a preemptive scheduler. As I see it, that issue appears orthogonal to distributed/non-distributed systems.

0. https://atomvm.org/

0 comments

k_g_b_3mo ago

Structured concurrency is also a Kotlin thing https://kotlinlang.org/docs/coroutines-basics.html#coroutine... and a Python thing https://vorpus.org/blog/notes-on-structured-concurrency-or-g... and before that it was a C thing https://sustrik.github.io/250bpm/blog:71/

kibwen3mo ago

> Easier to reason about, sure, fine. Your earlier comment claims the actor model is a dead end in non-distributed systems.

If you have two ways of structuring something, and the worse way is so predominant that it obscures even the existence of the better way, that's a dead end in my book. In the pre-structured-programming days when people had to fight tooth and nail to get people to acknowledge the value of `if` and `while` over `goto`, we would have also called `goto` a dead end; it's plain to see that we would be in a worse place today if the structured programming advocates had not managed to convince everyone of its superiority.

> Results from my quick search on structured/unstructured concurrency were all references to Swift. Is this a Swift thing?

I have no idea whether Swift supports it, but no, it's not a Swift thing any more than `while` and `if` are a Python thing. I highly, highly encourage people to read the linked blog post, it will be the best use of your time today.

eaurougeOP3mo ago

I read the article you referenced. It's based on, and described wrt, Python's `async with` (so quite a few layers of abstraction), so I can't say with certainty how it's implemented. But, as I noted earlier, it isn't really that different from a run-till-completion task scheduler and is not particularly novel or interesting, imo.

j / k navigate · click thread line to collapse