Comment by parenthephobia | Hacker News Reader

Comment by parenthephobia | Hacker News Reader

Parent Full thread

But I think I do care.

When I see

    var x = await bar();

I know that other code, outside bar(), may have run during the execution of that statement.

Also, the JS approach makes composing asynchronous operations simple:

   var x = bar();
   var y = bar();
   return await x, await y;

Both bar invocations can run in parallel. If, say, each invocation of bar fires off an Ajax request that takes a few seconds to come back, that can be a significant saving.

It's unclear (to me) how that would be done in Lua without complicating the API.

It is a false security. If you call a function either you know what it does (so in lua you would know whether it call yield) or you don't and it could still be calling arbitrary code, so you have to code defensively and think about reentrancy. The only reason for await is that it normally needs to save less state (a single frame) than a full coroutine yield (a whole stack).

Also lua-like stackfull coroutines don't prevent firing multiple asynchronous operations at the same time (like in your example), they only make the waiting much more peasant.

OpenResty, for one, allows that via grouping queries, rather than results:

    local requests = { "/mysql", "/postgres", "/redis", "/memcached" }
    local responses = { ngx.location.capture_multi(requests) }

    for i, response in ipairs(responses) do
        print(response.foobar)
    end

But instead ngx could lazy-evaluate responses with help of metatables (see my other comment).

Reply on news.ycombinator.com