Wanted to share with everyone series of podcasts about the topic.
The topic is quite complicated, so maybe this helps you to better understand what is it all about.
They discussing it mostly from C++ perspective, with some Haskell ideas.

D package with this approach: https://code.dlang.org/packages/concurrency

Podcast series:
https://adspthepodcast.com/2025/04/25/Episode-231.html
https://adspthepodcast.com/2025/05/23/Episode-235.html
https://adspthepodcast.com/2025/05/30/Episode-236.html

On Monday, 2 June 2025 at 19:22:47 UTC, Sergey wrote:

Why should "Structured Concurrency" be viewed as a better approach than CSP (or Actors for that matter)?

DF

On Monday, 2 June 2025 at 19:32:03 UTC, Derek Fawcus wrote:

Here's the most popular explanation:

https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

The main thesis (quoted from the article's conclusion) is this:

On Tuesday, 3 June 2025 at 06:06:24 UTC, Paul Backus wrote:

Thanks. I'll have a read of that later.

The flaw I've seen to date in the arguments against CSP (and Actors) in favour of 'Structured Concurrency', but which I do view as valid against raw threads, async/await type abstractions is the scope of application.

The way I approach CSP and Actors is to apply them to 'large' chunks of natural concurrency, and hence generally avoid shared data access.

Whereas the raw threads + locks, async/await and friends and implicitly 'Structured Concurrency' seem to be targetting 'fine grained' conncurrency decomposition, even to the level of individual functions calls. This I view as inherently difficult to reason about, and possibly SC then provides some form of aid in reasoning.

Now one could use CSP and Actors in a similar way, and there they would likewise be equally difficult to reason about, but I suggest they tend to encourage different and higher level form of decomposition.

There the same reasoning issues don't arise, and moreover there are tools one to apply to prove the network/graph one has for CSP. (I'm not sure if the same applies for Actors).

The obvious trade off which one makes when using CSP is the risk of deadlock.

However the above tools are supposed to avoid that. I've not yet tried them, since I've yet to hit/create a sufficiently difficult graph which challenges manual analysis. However it may still be worth using such tools if the graph may change under long term support of the program.

Even without such use I find that with sufficient logging (which is not really a lot) it is easy to reason through any remaining deadlocks once the arise during testing. Whereas it is incredibly difficult to reason through the trigger cause with shared data update (even under locks) when it occurs from multiple concurrent call graphs, which would happen under the other methodologies (including, I believe, SC).

So I generally see SC as tackling the wrong problem, however I shall give your reference a fair crack of the whip.

(I listened to the first podcast above; I've yet to get to the other two)

On Monday, 2 June 2025 at 19:22:47 UTC, Sergey wrote:

another OT idea . perhaps D needs some kind of 2nd tier package bundle or even 3rd tier package. I mean that this kind of package must be somewhat impoertant that it gets downloaded for 137217 times.

Otherwise it get lost somewhere in the forum, and int code.dlang.org, never be found and be used. Especially for newbie . Like me.

So maybe the download has some extra batteries

On Tuesday, 3 June 2025 at 16:19:50 UTC, f wrote:

come join the dark side of opend

On Monday, 2 June 2025 at 19:22:47 UTC, Sergey wrote:

Implementer here. Thanks for the link and ama.

On Monday, 2 June 2025 at 19:32:03 UTC, Derek Fawcus wrote:

Some more reading: https://skoppe.github.io/dconf-2022/6

In short: "Structured concurrency organizes concurrent tasks as tree-like hierarchies. This means that any child task is logically nested within its parent. When a parent task finishes, it waits for all its child tasks to complete or is automatically cancelled if the parent task fails."

This tree-like hierarchy achieves 2 important things:

• It improves reasoning of the code, like structured programming did;
• It ensures lifetimes of concurrent tasks follow the same structure, instead of the fire-and-forget approach.