Expecting structured concurrency to have prevented 3/4 of the bugs seems optimistic to me. I haven’t looked at the raw data (is it even available?), but they tell us that ~1/4 of the bugs were classic race conditions, and I wouldn’t expect structured concurrency to have any direct effect on those. (I guess we could hypothesize about an indirect effect where structured concurrency makes things simpler overall so you have more brain power left over to spend on noticing race conditions, but that’s beyond the scope of this methodology.)
And @elizarov wrote a nice article here about a deadlock bug when using channels in a structured program – structure is nice but it’s not a panacea:
OTOH, all mistakes in using the
WaitGroup API seem like they’d trivially be prevented. And more interestingly, the two examples in their paper that I had to stare at the longest to understand – Figs. 6 and 12 – both involve a standard module’s surprising use of background goroutines. In a structured language, you couldn’t have those APIs. And maybe you wouldn’t need them, since they both involve timeout/cancellation handling, and in structured languages we expect those to be handled by the runtime.
I just can’t tell how representative these examples are. Someone could email the authors to ask for access to the data or invite them to participate here, but I don’t have the time myself right now.