> Erm, no [..needless snark, insinuates I'm confused.. proceeds to largely restate Smith's article and himself, though a little better this time; Good job! but does not solve the problem if a user wants even "most" of the N answers..]
I suppose I could have instead said "exist in this one replacement idea[..]could cost more than you save either in other constructs or in mitigations" or something similarly guarded/defensive. Seems you probably would have picked yet another strawman or willfully obtuse reading to attack rather than argue in good faith.
If you do not have positive "arsenal addition" suggestions to solve the essence of the problem I mentioned -- which I am pretty sure many care about -- whatever gripe you might have with how I describe it then I don't think we have anything more to say to each other here.
To the extent that you're still looking for the drop-in replacement you're going to of course be disappointed, this is why that Python hack doesn't do what you thought it did. Composition is what makes the higher level constructs worth having despite the fact they aren't drop in replacements and don't deliver the raw power of the simpler idea.
I encourage you to think about such higher level, composable, structures. You can imagine them as a library calling your more powerful primitive if you like, but don't be surprised if that doesn't turn out to be the reality.
Your rate of misreading & over-attribution with the seeming intent to inflame is high. Trying to be enough of a troll to rollback a bit the perception Rust has a welcoming community?
If you/anyone is curious about a multi-prog.lang project starting from structure and later building arsenals in the senses here, there are worse places to start than the 25+ year history of https://en.wikipedia.org/wiki/OpenMP . There may be records to be found of board meetings/rationales discussing trade-offs & limitations.
> You can cobble together "unstructured" jumps on top of the structured exception system as in pygoto.
As I explained, all pygoto is actually doing is recursively invoking Python's interpreter. It's a clever hack, but you can't actually use this as go-to, which is why the trivial loop doesn't do what you'd expect.
> Trying to be enough of a troll to rollback a bit the perception Rust has a welcoming community?
I'm sure Rust's "welcoming community" can point you to more agreeable people if that's what you're looking for.
> the 25+ year history of https://en.wikipedia.org/wiki/OpenMP
I am an old man, and this sort of thing makes me feel older every day. Yes I am aware of OpenMP, but I learned this stuff with MPI since OpenMP didn't exist until I was a graduate.
Did you notice, in reading that 25+ year history (it would be about 30 years for MPI) a gradual trend? That things everybody was sure were just too abstract and high level to be useful in 1995 are today mainstream and of course modern versions of these APIs must offer them? Complexity is inevitable, and so ease of composition becomes more important and the structured concurrent primitives are easier to compose.
Just the other week, I was eating lunch with some people from the floor above, who look after our supercomputers and they were moaning about a high value user who has sloppily left some old spin-when-done code in the version they're actually running. He's likely bringing in enough revenue to justify the supercomputer on his own, but it'd be nice if his code would correctly detect "I'm done, exit" and let other jobs run without manual intervention. He hasn't done this on purpose because he's evil, he just did what was easiest in the 1990s tools he's using. Structured concurrency could have made it easier for his program to have the same performance and exit cleanly with no effort.
Er, no. I can imagine Dijkstra may have faced similarly confused people, who just couldn't understand how (for example) a loop feature should replace their use of a go-to for conditionals. Dijkstra does not propose a single new language feature to replace go-to one-for-one, and indeed makes clear in his letter that although this has been proven technically possible it's obviously the Wrong Thing™, likewise the replacement for go statements isn't a single "must wait for last of N" feature.
Just as modern programs typically have loop constructs, and conditional constructs, and procedure constructs even though a go-to statement could have expressed all these and more, the idea is that you could have several different concurrency mechanisms, each better suited for its purpose than the "go statement" and similar features today.
I think we'd want semi-short-cutting concurrency for example. Suppose there are computations F1, F2, F3, F4. In serial programs we can imagine writing f1() && f2() && f3() && f4() to have each computation happen only if the previous computation was unsatisfactory in some way because we have short-cutting && operator. But as a concurrency primitive you might like to have a way to perform F1, F2, F3 and F4 so that perhaps all four might happen however once you have a satisfactory answer from any of them the computation overall stops. Unlike the short cutting && operator this would not promise that F4 doesn't run if the others succeed but it would promise not to expend further computation after the answer is discovered.
Now, of course you can build this from the more powerful "go statement" primitive, but that's not the point here, you could build the short-cutting && operator from the go-to primitive too. The point is that having a sufficient arsenal of such structures provides clearer concurrent programming which empowers us to write more complex concurrent programs that are correct.