undefined | Better HN

0 pointswokwokwok8y ago0 comments

The point of the construct is not explicitly waiting for child tasks/threads/whatever, but that as a formal restriction, you cannot leave the scoped block with unresolved tasks.

I don't believe either of the constructs you've mentioned do this, and I'm not aware of any that do.

The trivial counter example would be a deeply nested `setTimeout(..., 5000)` inside the javascript code.

It doesn't matter if you've called Promise.all or not.

Also, regarding parallelism: Obviously async/await are for that; this is basically pitching an equivalent construct for parallel processing.

I think this is novel, frankly, and the alternatives being thrown around by people are by people who didn't read the article.

0 comments

3 comments · 1 top-level

joshuamorton8y ago· 2 in thread

>The trivial counter example would be a deeply nested `setTimeout(..., 5000)` inside the javascript code.

Well of course, setTimeout isn't async/await based, its callback based. If instead you only had this api, you could make that formal assertion:

    await promiseSetTimeout(time).then(...);

And in fact you can write promiseSetTimeout today!

So basically, async/await provides this as long as you only use async/await. In JS you can't formally assert this because there are functions that subvert the normal control flow, but if you outlaw those, you absolutely can.

wokwokwokOP8y ago

> as long as you only use async/await...

Well, what if you don't?

That's the point.

The proposed construct does not require that: I'm not saying its better or worse; I'm just pointing out that it's different.

Obviously if you choose to avoid branching code in your functions, they won't branch; what's novel here is that the closing scope (ie. in this case, the collapse of the python with block) triggers a collection of all the ambient tasks started in that context.

I'm sure you could implement something similar in javascript, but it is not the same as Promise.all.

joshuamorton8y ago

>Well, what if you don't?

This is kind of a silly question. Its always possible to subvert a safe construct system if you try hard enough. You can write unsafe blocks in rust. You can pass in a callback to a nursery, as is described in the article.

>The proposed construct does not require that

Well, kind of. The article actually explicitly states that

>Here's a simpler primitive that would also satisfy our flow control diagram above. It takes a list of thunks, and runs them all concurrently:

which is equivalent to promise.all, satisfies the invariant nurseries do, except in very specific circumstances (unbounded while loop-y constructs). And you just simply can't use promise.all in that situation.

1 more reply

j / k navigate · click thread line to collapse