Re: (not) handling new programming idioms with grace

[Nagaev Boris <bnagaev@...>]

On Sun, Jul 15, 2018 at 10:22 AM, John Belmonte <john@neggie.net> wrote:
> It's been about 10 years since my post "state of the Lua nation on resource
> cleanup" [1].  The only relevant thing that's happened in this area since
> then was Lua getting pcall + coroutine love in 5.2.
>
> My position on Lua's need for some type of scope exit hook is only stronger
> these days.  It's not just about resource cleanup.  For example, there are
> some very interesting concurrency and cancellation control structures being
> developed as Python libraries [2] [3] which would be cumbersome and much
> less effective in a language lacking the equivalent of Python's "with"
> statement.
>
> To summarize the concurrency control structure, called a "nursery": all
> spawned tasks within the scope block are owned by that scope's context
> manager, and the scope will not end until all child tasks are completed.  If
> a child has an exception, all other child tasks will be cancelled and the
> error will be propagated.  I'm well versed in trying to use Lua function
> lambdas for this kind of problem.  The result is not satisfying.
>
> Regards,
> --John
>
>
> [1] http://lua-users.org/lists/lua-l/2009-01/msg00333.html
> [2]
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
> [3] https://vorpus.org/blog/timeouts-and-cancellation-for-humans/
>

Hey John!

I looked through your post [2] "Notes on structured concurrency, or:
Go statement considered harmful". There is sync.WaitGroup type in Go
that allows you to make sure all launched goroutines have exited:

var wg sync.WaitGroup
for i := 0; i < 10; i++ {
  wg.Add(1)
  go func() {
    defer wg.Done()
    // do something
  }()
}
wg.Wait()

> In most concurrency frameworks, go statements cause the exact
> same problem: whenever you call a function, it might or might not
> spawn some background task. The function seemed to return, but
> is it still running in the background?

There are cases when this is a desired behavior. For example HTTP
request handler may start a backgroud task, but not wait for it to
finish.

In the section "There is an escape." you proposed to pass nursery
inside any function that may spawn goroutines. Isn't it too verbose?
In case you are troubleshooting goroutines leakage you have a lot of
tools in Go that show you how (call stacks) they were started and
where they are blocked. This issue is pretty rare from my experience.
Does it worth passing another argument into almost any function just
to cure it a bit? Go is the language of compromises (as opposed to
Rust), that is why it has GC and "go" statement out of box - it is
lesser evil. Just my few cents.

-- 
Best regards,
Boris Nagaev