[colordrops]

> Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O.

That's non determinism from I/O, not from the callback or the setTimeout. setTimeouts are called in order based on schedule time.

And you can't blame non-determinism in JS on I/O. No language in existence is deterministic based on that measure.

[flagxor]

This seems rather racy in Chrome, despite the I/O being deferred to the end :-)

  (function() {
    var x = '';
    setTimeout(function() { setTimeout(function() { x += 'a'; }, 6); }, 4);
    setTimeout(function() { setTimeout(function() { x += 'b'; }, 5); }, 5);
    setTimeout(function() { console.log(x); }, 50);
  })();

It's a fair point that generally I/O is the source of the bulk of the non-determinism in most JS programs. But if that I/O non-determinism is present (as it is in most useful programs), event loops aren't a panacea to avoid peril from it.

Concurrency introduces another source of non-determinism. But just as good programs use care with the ideally limited amount of code responding to events, good concurrent programs use similar care with access to shared state.

I'm unsure if the strawman syntax proposed encourages that care, but it is interesting that it can at least be done without breaking basic safety + performance. With SharedArrayBuffer on the way, we'll get all the non-determinism of parallel execution peeping through to JS without a particularly JS friendly syntax, so it's at least worth thinking about if something should be added to JS.

[olau]

I object to the term "similar care". There's a big difference in what it takes to understand thread issues compared to single-threaded event-based systems.

For instance, if I'm not mistaken, your setTimeout thing is relying on precise timing. But this is documented when you look up setTimeout. It's not difficult to understand.

How to use locks and conditions/monitors correctly IS difficult to understand. You can't just read a few lines in the API documentation and proceed on to write correct code, beyond small toy examples.

[flagxor]

setTimeout is obviously a simpler primitive to understand in isolation than monitors/conditionvars, but I would argue that when used in equally complex scenarios, similar challenges emerge.

Something like Dinning Philosophers is no less tricky to express + understand with an event loop, and with JS's async await probably would most cleanly be expressed in a style that mirrors a monitors/conditionvars version.

The fact that JS has added async await suggests demand for the convenience of concurrent blocking threads. While async-await manages to separate out non-async code to a degree, once an await happens, the global state can also be arbitrarily mutated no differently than with threads.

  function block() { return new Promise(function(a,b) { setTimeout(a, 0); }); }
  var x = 0;
  (async function foo() {
     x = 1;
     await block();
     console.log(x);
  })().then();
  (async function bar() {
     x = 2;
  })().then();

Concurrency is hard, but event loops aren't a magic wand.