4 ms·

In addition to making await the default, one could make async the way to split off work: async foo() { let y = awaited(); // as in article let p = asyn

by clord 4y ago

In addition to making await the default, one could make async the way to split off work: async foo() { let y = awaited(); // as in article let p = async notAwaited(); // do stuff let z = await p; }

treve 4y ago
On a surface level this is the difference between Go and Javascript. In Javascript you opt in to waiting (await keyword) and in Go you opt out (go keyword)
- candiddevmike 4y ago
  As someone who writes Typescript, I still don't understand why I would not opt into waiting. Even my linter yells at me when I don't await, return a promise, or mark a function async, and my JavaScript call stack is typically very serial. Am I doing something wrong? How do you or why would you avoid waiting?
  - treve 4y ago
    Some examples of when I don't immediately await a function that returns a promise: 1. I pass it into Promise.all(). This one is a little obvious but I think it counts as you pass in non-awaited promises. 2. I store the promise I receive in a variable, that I can re-use to de-duplicate multiple in-progress calls. 3. I anticipate a future call, and fetch data in the background. Those are some real examples I've used, but I can also image my HTTP server kicks off some process that's not consequential for the current request, which would also happened asynchronously (and maybe immediately return a 202. My HTTP framework doesn't use callbacks unlike express so functions need to return to send a response). If you use React, calls in useEffect are also typically not awaited because the callback to useEffect does not support async functions. I'd generally agree though that most of my code is also very linear, and the few places I need to weirder stuff tends be in the libraries I maintain.
  - josephg 4y ago
    The simple answer is that there’s lots of instances in which it’s useful to interact with promises, instead of immediately await-ing them. Some instances off the top of my head: - Promise.all lets you do work in parallel. Very useful if you have a set of network requests to make, or things like that - Sometimes I want multiple parts of my program to respond to some event happening. You can use a promise as a simple one shot event dispatcher. Eg: this.p = fetch(…) … then elsewhere, from multiple call sites: foo.p.then(…) You can use this for http requests, user actions (make a promise which resolves when the user closes the form) or for dynamically importing a module. I’ve used this a lot with for webassembly modules in the browser. Multiple bits of code can all wait for the module to load and then start using it as soon as it’s ready. And once it’s ready, the promise will resolve immediately. I’m sure there are other uses, but these are things I’ve used raw promises for. They’re handy!
  - wruza 4y ago
    I do that all the time (exaggerated). const p1 = heavy_foo() const p2 = heavy_bar() await some_baz() const r2 = await p2 … return [await p1, r2, …] It is useful in “threaded” code which does many things in parallel runs. Or in this code: const [p, done] = block() obj.on("event", done) const res = await p … The implementation of block() is left as an exercise for the reader ;)

by clord 4y ago

In addition to making await the default, one could make async the way to split off work: async foo() { let y = awaited(); // as in article let p = async notAwaited(); // do stuff let z = await p; }

treve 4y ago

On a surface level this is the difference between Go and Javascript. In Javascript you opt in to waiting (await keyword) and in Go you opt out (go keyword)

candiddevmike 4y ago
As someone who writes Typescript, I still don't understand why I would not opt into waiting. Even my linter yells at me when I don't await, return a promise, or mark a function async, and my JavaScript call stack is typically very serial. Am I doing something wrong? How do you or why would you avoid waiting?
- treve 4y ago
  Some examples of when I don't immediately await a function that returns a promise: 1. I pass it into Promise.all(). This one is a little obvious but I think it counts as you pass in non-awaited promises. 2. I store the promise I receive in a variable, that I can re-use to de-duplicate multiple in-progress calls. 3. I anticipate a future call, and fetch data in the background. Those are some real examples I've used, but I can also image my HTTP server kicks off some process that's not consequential for the current request, which would also happened asynchronously (and maybe immediately return a 202. My HTTP framework doesn't use callbacks unlike express so functions need to return to send a response). If you use React, calls in useEffect are also typically not awaited because the callback to useEffect does not support async functions. I'd generally agree though that most of my code is also very linear, and the few places I need to weirder stuff tends be in the libraries I maintain.
- josephg 4y ago
  The simple answer is that there’s lots of instances in which it’s useful to interact with promises, instead of immediately await-ing them. Some instances off the top of my head: - Promise.all lets you do work in parallel. Very useful if you have a set of network requests to make, or things like that - Sometimes I want multiple parts of my program to respond to some event happening. You can use a promise as a simple one shot event dispatcher. Eg: this.p = fetch(…) … then elsewhere, from multiple call sites: foo.p.then(…) You can use this for http requests, user actions (make a promise which resolves when the user closes the form) or for dynamically importing a module. I’ve used this a lot with for webassembly modules in the browser. Multiple bits of code can all wait for the module to load and then start using it as soon as it’s ready. And once it’s ready, the promise will resolve immediately. I’m sure there are other uses, but these are things I’ve used raw promises for. They’re handy!
- wruza 4y ago
  I do that all the time (exaggerated). const p1 = heavy_foo() const p2 = heavy_bar() await some_baz() const r2 = await p2 … return [await p1, r2, …] It is useful in “threaded” code which does many things in parallel runs. Or in this code: const [p, done] = block() obj.on("event", done) const res = await p … The implementation of block() is left as an exercise for the reader ;)