On Thu, Aug 16, 2018 at 08:30:26PM +0000, John Belmonte via Digitalmars-d wrote: [...] > (Andrei, I hope you are reading and will check out > https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ > and https://vorpus.org/blog/timeouts-and-cancellation-for-humans/)
I read both articles, and am quite impressed by the revolutionary way of looking at concurrency. It provides a clean(er) abstraction that can be reasoned about much more easily than currently prevalent models of concurrency. Seems it would fit right in with D's message-based concurrency communication model. [...] > These are novel control structures for managing concurrency. > Combining this with cooperative multitasking and explicit, > plainly-visible context switching (i.e. async/await-- sorry Olshansky) > yields something truly at the forefront of concurrent programming. I > mean no callbacks, almost no locking, no explicitly maintained context > and associated state machines, no task lifetime obscurity, no manual > plumbing of cancellations, no errors dropped on the floor, no shutdown > hiccups. I'm able to write correct, robust, maintainable concurrent > programs with almost no mental overhead beyond a non-concurrent > program. Indeed. It certainly seems like a promising step toward addressing the nasty minefield that is today's concurrent programming models. However, it would seem to require language support, no? It's going to be a tough sell to Walter & Andrei if it requires language support. (Though IMO it's worth it.) One potential problem point is C/C++ interoperability. Once you can call into the wild world of arbitrary C/C++ code that may spawn threads and do other low-level concurrent things, all bets are off and you can no longer provide the above guarantees. But we might be able to work around this with a mechanism similar to @safe/@system/@trusted, to isolate potentially encapsulation-breaking code from code that's been vetted to not have unwanted concurrent side-effects. Then within the realm of "well-behaved" code, we can reap the benefits of the new concurrency model without being crippled by the potential of interacting with "badly-behaved" code. [...] > I'd like to see a D library supporting these control structures (with > possibly some async/await syntax for the coroutine case). And of > course for vibe.d and other I/O libraries to unify around this. If this is possible to implement without requiring language support, that would be a major win, and would be much more likely to be acceptable to W & A. > I'll go out on a limb and say if this could happen in addition to D > addressing its GC dirty laundry, the language would actually be an > unstoppable force. [...] Not sure what you're referring to by "GC dirty laundry", but IMO, the GC gets a lot of undeserved hate from GC-phobic folk coming from C/C++. While there's certainly room for improvement, I think the GC ought to be regarded as one of those modern features that are essential to D's success, not the illegitimate step-child that everyone tries to avoid. It liberates the programmer from being constantly bogged down with the nitty-gritties of low-level memory management issues, and frees the mind to focus on actually solving the problem domain the program is intended to address. Just like this new concurrency model liberates the programmer from constantly having to worry about data races, deadlocks, and all the other nice things traditional concurrency models entail. ;-) T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
