concurrency call to arms

[John Belmonte]

On Friday, 17 August 2018 at 06:36:36 UTC, rikki cattermole wrote:
> Because we have an event loop, we don't need a nursery! It 
> comes free of charge. It also means we don't need that with 
> statement... hang on that now becomes await and async! Just 
> without the await (auto added in scope(exit), and compiler can 
> merge them into a single function call ;) ).

H. S. Teoh already made some fair points in response.  I'll just 
add that having task lifetimes defined by nested blocks mixed 
right into the normal program flow is powerful, and trying to 
emulate this with function scopes is not sufficient (return 
doesn't work, exception handling is a mess, etc.).

It's a subtle thing that you actually must try to appreciate.  If 
it were obvious we would have had this decades ago.

Regarding async / await, "auto" anything defeats the purpose:  
they are primarily markers to help programmers reason about the 
code.

    value = await some_container.async_get(key)
    modified_value = transform(some_std_lib_func(value))
    /*... a bunch of non-await code that does more stuff with 
modified_value ...*/
    some_container.set(key, modified_value)
    await foo()

Essentially all code between await keywords can be considered 
atomic.  This greatly reduces the need for locking, as well as 
the cognitive load of reasoning about race conditions and access 
to shared state.  Contrast this with say go's coroutines, where 
context switches can happen on any function call 
(https://golang.org/doc/go1.2#preemption).

Regards,
--John