Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I really don't see the need for such a syntax. If I say:

  Foo foo = someFoo();
  ...
  String content = foo.getContent();
I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined.

There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated.

The biggest problem I see is a when you use this functionality in a loop of independent executions (when the results of any given loop don't depend on the results of prior loops):

  for(Foo foo: asyncFoos()){
      Foo foo = someFoo();
      ...
      result.add(foo.getId(), foo.getContent());
  }
The problem here is that the use of a for loop will introduce latency, potentially dramatically increasing execution time.

Now you can either replace this "for" with some sort of "for-each" type of block, or you can go async all the way and treat "for" as "for-each" and any referenced result of a prior iteration as yet another async value.

That covers sets and singletons, I imagine that any other situation that needs to be dealt with can also be covered on the compiler side of things with only minimal changes to syntax.



I personally think that the syntax is great considering it's being added to an existing language. await/async allows you to opt-in to having your code behave in a synchronous-like manner, when you want it to.

One of the best things about JS/Node is that you can wait on I/O from different sources at the same time and since the async/await syntax is just sugar over Promises, you can do things like:

  const [user, notifications, messages] = await Promise.all([
    getUser(),
    getNotifications(),
    getMessages(),
  ]);
Instead of having to wait on I/O sequentially like:

  const user = getUser();
  const notifications = getNotifications();
  const messages = getMessages();
if awaiting were implicit.


It's usable, it's powerful and it's not overly verbose - but I'd contend it's adequate rather than great.


You may not care, but the computer does!


Perhaps it does, but my point was it does not need to. The only thing that needs to be ensured is that calls to the object are not issued before the result is returned and assigned - for all code that occurs between the call to get the object and the first actual access of the object, it does not matter.


Why doesn't the computer do it for me?


Agreed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: