On Tuesday, 28 August 2018 at 20:05:32 UTC, Russel Winder wrote:
But that is the point, this is Python specific, and yet the
motivating example is a misunderstanding of how Go is used.
This inconsistency seriously undermines the general argument.
I don't believe I misunderstand how Go is used. Trying to solve
every concurrency issue with processes and channels-- were you
need
some data silo to manage chunks of shared state-- is not exactly
friendly to
casual or novice programmers, which is an important segment of the
population.
async/await is a means to explicitly mark points of context
switching in API's and code. It applies to threads,
coroutines, remote processing, or anything else which may
allow something else to modify system state while you're
waiting.
Certainly it is a language structure to support yield to the
appropriate scheduler, the question is whether a language
structure is required or it can be handled with library
features. I suspect language feature makes things easier of
implementation.
I'm in total agreement about using a library solution if
possible, and
stated that in the original post.
Important news relevant to this thread: Kotlin has announced
support of structured concurrency in its standard coroutine
library, citing the "Go statement considered harmful" article as
inspiration.
https://medium.com/@elizarov/structured-concurrency-722d765aa952
Kotlin appears to be a good example of supporting many
concurrency mechanisms via a library. From the manual:
Many asynchronous mechanisms available in other languages can be
implemented as libraries using Kotlin coroutines. This includes
async/await
from C# and ECMAScript, channels and select from Go, and
generators/yield
from C# and Python.
Furthermore it generalizes across different ways of managing
shared state. A concurrency scope can span threads, so shared
state must be accessed through locks or channels; or a scope can
be pinned to a single thread, allowing the programming simplicity
of Trio's single-threaded model.
