Discussion: "Notes on structured concurrency, or: Go statement considered harmful"

goroutines with channels solve a lot of your objections except that of handling serious errors. By convention you can pass along an error but you can’t pass it back to the caller of the channel.

You might be able to implement a nursery by convention in GoLang by forcing your GoRoutines to write their errors to an Error channel which was monitored by the nursery. By convention most GoRoutines take a “done” channel as an argument. When the nursery decides to stop processing due to an error in on one of the GoRoutines, the error monitoring GoRoutine can close the done Channel.

The fact that there is no test for “is this channel closed” is a hassle because ideally there are multiple conditions under which you would want to close everything down, and ideally you need a broadcast to do it. The hack is that any routine desiring to close the done channel has to send a message on yet another channel “Please close shit down” then the monitoring channel on that one has to close the “done” channel. Then once all these messaging channels are closed, close the “please close down” channel. Doable. but way complex to get it right.

And without any sort of templating mechanism pretty likely to have to be hand coded in every nursery.

Anyway those are my first thoughts without having tried to write all this. I am very familiar with GoLang though and use GoRoutines regularly without your issues.

Is there some discussion on how structured concurrency works with GUI frameworks?

Of course, you can do the trivial thing that you wrap the instantiation of the GUI application in a giant nursery that you pass to it so that all the event handling callbacks can live in it. Has anybody come up with some finer grained approach, and is it even desirable?

You could probably do one per window if you had some windowing framework that abstracts filtering of events by window really well but it does not seem to be common.