Hacker News Reader

Comment by protoduction | Hacker News Reader

You are right that it's a terrible idea (I hope it was clear from the article that it's an experiment and should stay that way), but could you help me understand why this is fundamentally broken?

I would say that by using setInterval you are buying into this kind of behavior and would have to create your own synchronization.

If you are saying that this transpilation step changes the semantics of the code, then I completely agree!

View on HN

For a practical example, take this code I wrote recently:[1]

    const backends = {}
    
    async function setupBackend(host) { /* boot server */ }

    function getBackend(host) {
        if (!backends[host]) {
            backends[host] = setupBackend(host)
        }
        return backends[host]
    }

That if block is effectively a critical section: it relies on explicitly not awaiting the result of setupBackend(), so that the promise will be stored into backends[host] (to be reused by subsequent calls to getBackend()) before anything else can happen. Injecting `async` will break this behavior, causing the backend to be booted multiple times.

[1] https://github.com/wolfgang42/webd/blob/8cf28447468dd4745262...

Why not simply set some intermediate value to indicate that the backend is booting? Such as:

    const backends = {}
    
    async function setupBackend(host) { /* boot server */ }

    function getBackend(host) {
        if (!backends[host]) {
            backends[host] = 'FLAG' // or something
            setupBackend(host)
                .then(backend => backends[host] = backend)
        } else if (backends[host] === 'FLAG') {
            // no-op
        } else {
            return backends[host]
        }
    }

Subsequent callers of getBackend also need to be able to await on the backend boot before they can do anything useful. If the backend is currently booting, your function will return undefined in the “no-op” case, giving the caller no way to tell when it’s finished (other than retrying, I suppose).

I tried writing some code for this comment that used an explicitly constructed Promise as the intermediate value with some logic to resolve it once setup was complete, but then I realized that it had exactly the same problem with that being implicitly waited on. Maybe there’s some clever way to work around this but it’s going to be a lot more complicated.

Of course, if you do insist on a JS dialect with implicit await, the easy fix for this problem (since you’re transpiling anyway) is to just introduce a `noawait` keyword that turns the await insertion off for a block, to explicitly mark it as atomic.

[ETA: also, in the general case there’s a race condition if someone calls the function again while it’s awaiting the initial flag value. That doesn’t happen with your code because the OP library happens to not await literals, but that’s kind of fragile: I can easily see a situation where someone tries to introduce e.g. a counter into the flag and causes a non-obvious race.]

If you have code like:

let x = 0;

doSomethingAsync(); // does not touch x

console.log(x);

There's no guarantee that x will have the value 0 by the time you get to console.log(x). The value of x might have been changed by an outside function that just happened to run between your statements. In synchronous JS this would never happen as callbacks are scheduled to run only at the end of a function, and if they change x the change will only be applied after x is printed.

The change in behavior will break a lot of existing code, since the synchronous behavior of a function is a core feature and assumption of the language.

Isn't that only really a problem with global variables? Local variables would be safe from this kind of behavior I'd think.

Thank you for taking the time to explain :)

I completely see that this will break existing code, but I don't see how this is different from the behavior of Go (where the setTimeout code would be something in a different goroutine) or Python?

That is false except for the case that x is a global variable, no outside function can change the value of x, only in-scope procedures can do that.

I guess it is true in this particular example, since 0 is a primitive and assigned by value. But what if you got it from an outside function, such as init(), and it was an object instead? Then you would have to guarantee that the return value of init() would not change between statements.

In the end this shows that JS is unequipped to handle such behavior without significant changes to the core language.

> But what if you got it from an outside function, such as init(), and it was an object instead? Then you would have to guarantee that the return value of init() would not change between statements.

Then even in a synchronous context you'd have no guarantee that it wouldn't be modified:

  function soSomethingSync() {
    window.someObj.someProp = 12;
  }

  let x = window.someObj;

  soSomethingSync();

  console.log(x)

This has nothing whatsoever to do with sync vs async.

It is one of the main reasons people like immutability/functional programming. But that's its own topic.

You are guaranteed that only code you call will be run. Sure you can call anything you want but the point is you have full control over what that is. If you yield execution with an await, you no opt out of that guarantee.

Its a fundamental concurrency pattern used in a lot of languages, often for UI threads and such. There's a lot of information on this topic and it certainly is about async/yielding.

Then this is not related to async/await but regardless even then JavaScript has always had the ability to change the writability of properties such that trying to change a property in an object will yield a no-op with Object.defineProperty, and now with newer features like Object.freeze and private properties.

Not just globals, anything passed in or passed out, right?

Reply on news.ycombinator.com