Hacker News Reader

Comment by ermir | Hacker News Reader

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.

View on HN

> 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.

Reply on news.ycombinator.com