async/await -> await/async: a simpler, less error-prone async syntax

T.J. Crowder tj.crowder at farsightsoftware.com
Mon Dec 4 13:57:18 UTC 2017


On Mon, Dec 4, 2017 at 12:52 PM, Steven Mascaro <subs at voracity.org> wrote:
> 3. I think the principle "prefer explicit to implicit" argues in
> *favour* of the proposal (and against the existing syntax).
> You gave the example:
>
> ```js
> let x = foo();
> let y = bar();
> ```
>
> Imperative language conventions imply the second statement only
> executes after the first is fully complete. But if `foo` and
> `bar` are defined as async functions, the second statement likely
> starts executing before the *real* work being done in the first
> statement is complete.

I understand what you're saying there, I just disagree. I said I know the
**temporal** sequence when looking at that code, and that's what I'm saying
we should continue to be explicit about when it isn't "this then that"
without the job yielding and potentially another job being scheduled in the
meantime. That kind of yield for other work is a big deal and should, in my
view, be flagged. I get the desire for it to represent the *logical*
sequence instead without flags, I just think it's too late to do that to
JavaScript. I keep flirting with the idea of a purely-async or
async-is-the-assumption language and this is part of why, but I don't see
retrofitting JavaScript to be that language. Perhaps that's pessimistic of
me, but when these two functions have completely different temporal
semantics, I think it's time for a new language:

```js
(await () => {
    foo();
    bar();
})();
(() => {
    foo();
    bar();
})();
```

Maybe before the current `async`/`await` were added, but...

> If you're really committed to being explicit, then we should require
> the coder to specify how they want *every* call to an async function
> to be handled.

Clearly not, that's just reductio ad absurdum. We have a massively
well-established "If it's a plain call, it happens in the same job in
linear sequence" precedent. For me (and we just disagree on this, which is
fine), if it's going to be a yield back to the queue, it needs signifying.

Those are my $0.02, FWIW. Maybe I'm being old-fashioned. :-)

-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171204/432d5f7d/attachment-0001.html>


More information about the es-discuss mailing list