4 ms·

Here's a lazy third option: console.log('start') try { doA() doB() doC() console.log('finish') } catch (error) { consol

by trog 5y ago

Here's a lazy third option: console.log('start') try { doA() doB() doC() console.log('finish') } catch (error) { console.log(error) } It seems to me async/await is a desperate attempt to try to make JavaScript less painful to deal with because of its asynchronous execution nature. I am not a JS expert and have not had many opportunities to work with it extensively, but I confess I have always struggled with this when dealing with JS; I have often wondered if the (alleged?) performance gains from executing JavaScript like this outweighs [what I have always perceived as] the significant extra verbosity and complexity required to manage simply executing things in order.

yoz-y 5y ago
I don't understand your example, if would only work if your doA,B,C functions were synchronous, which completely changes the paradigm and use case. It's simpler yes, but very different. (simple example: if that function were to be run when you click on a button, now you have a frozen UI.)
- trog 5y ago
  Yep. I am just wondering if the paradigm of JS being asynchronous is just not worth the added effort in code complexity and all the workarounds that have had to be added in over the years to try to make it manageable. I personally find it a chore to work in JS compared to other languages that work the opposite way - everything is synchronous and things become a chore when you want to deal with async stuff. Again I have limited JS experience and have never enjoyed working with it (I just am not interested in front end stuff) so I'm sure it's stuff people get used to.
  - noahtallen 5y ago
    Could you clarify what the paradigm of JS being asynchronous means? Usually, async calls are actually “async” in that you’re doing a network request or something actually asynchronous. The reason they have to be async is that you cannot just block all execution or else other things can’t happen while the network request is happening. Which means your entire application grinds to a halt. Other languages solve this in a similar way IMO, with async/await and actual threads. JS doesn’t have threads, so you can’t fork a process to handle network stuff apart from UI. I personally think that async/await is a lot more straightforward to use than forming a process. Additionally, async/await allows you to wait when you need to. You don’t have to await a promise — you can just call it, and then it will work in the background. You’ll just not be able to respond when it finishes work. (Because you aren’t “wait”ing for it.) What are some other examples with easier async in other languages? I’m just confused what you’re trying to get at. Everything in JS is synchronous. You only have async when you have async. Which is a lot, because a lot of stuff in the web is async.
    - trog 5y ago
      Yep, sorry & thanks for your polite post in response to my basically unhinged ramblings (late night after a tough week, always a bad time to try to do anything). The poster jmull above basically wrote[1] what I was trying to say much more succinctly; this other post[2] is also more clear. Really I was just being snarky about the idea of shell scripting where you have to type 'await' in front of every command you want to run in a three-line file, like in the examples presented for this tool. 1. https://news.ycombinator.com/item?id=27080734 https://news.ycombinator.com/item?id=27080734 2. https://news.ycombinator.com/item?id=27077752 https://news.ycombinator.com/item?id=27077752
Raed667 5y ago
I wasn't attempting to defend JavaScript design choices. I'm just stating that working with blocking vs non-blocking code is now MUCH easier (and less error prone) since we have async/await. Callback-hell and Promise-hell were real issues that plagued any project of significant size.
- trog 5y ago
  Oh yeh sorry I didn't mean to give the impression I thought you were wrong. I 100% agree with you. I remember the first time I experienced "callback hell" (2016, for me, but I'm sure it was a huge problem for others before then) when I was doing some JavaScript stuff implementing Keybase's library for GPG support - I learned they'd built a whole separate JavaScript thing called IcedCoffeeScript[1] specifically to add await/defer support to get rid of those huge callback pyramids. 1. http://maxtaco.github.io/coffee-script/ http://maxtaco.github.io/coffee-script/
jmull 5y ago
I agree with this syntax, but it’s too late now (for JavaScript). To clarify, JavaScript could have made await the default for async functions, so that if you called an asynchronous function without putting any keyword in front of it, execution would block until the operation completed. In that design, there would be some keyword you would use when you did not want to wait. What they did: you have to opt-out of async execution by adding the await keyword. What they could have done: you opt-in to async execution by adding a keyword. They just chose the wrong default (IMO). It’s not a big deal — it’s easy enough to type “await” here and there. It’s bad, though, that you don’t really see the basic flow of control from examining the code making function calls. You also need to consult the function definitions to see which ones are async. Another option would be to have no default, and instead require that async functions be called with an explicit indication of whether they are to execute sync or async. That too heavy-handed, IMO. Fine for a statically checked language but not a dynamic one.
- trog 5y ago
  Thanks, this is basically what I was trying to say but is written so it actually makes sense.

by trog 5y ago

yoz-y 5y ago

I don't understand your example, if would only work if your doA,B,C functions were synchronous, which completely changes the paradigm and use case. It's simpler yes, but very different. (simple example: if that function were to be run when you click on a button, now you have a frozen UI.)

trog 5y ago
Yep. I am just wondering if the paradigm of JS being asynchronous is just not worth the added effort in code complexity and all the workarounds that have had to be added in over the years to try to make it manageable. I personally find it a chore to work in JS compared to other languages that work the opposite way - everything is synchronous and things become a chore when you want to deal with async stuff. Again I have limited JS experience and have never enjoyed working with it (I just am not interested in front end stuff) so I'm sure it's stuff people get used to.
- noahtallen 5y ago
  Could you clarify what the paradigm of JS being asynchronous means? Usually, async calls are actually “async” in that you’re doing a network request or something actually asynchronous. The reason they have to be async is that you cannot just block all execution or else other things can’t happen while the network request is happening. Which means your entire application grinds to a halt. Other languages solve this in a similar way IMO, with async/await and actual threads. JS doesn’t have threads, so you can’t fork a process to handle network stuff apart from UI. I personally think that async/await is a lot more straightforward to use than forming a process. Additionally, async/await allows you to wait when you need to. You don’t have to await a promise — you can just call it, and then it will work in the background. You’ll just not be able to respond when it finishes work. (Because you aren’t “wait”ing for it.) What are some other examples with easier async in other languages? I’m just confused what you’re trying to get at. Everything in JS is synchronous. You only have async when you have async. Which is a lot, because a lot of stuff in the web is async.
  - trog 5y ago
    Yep, sorry & thanks for your polite post in response to my basically unhinged ramblings (late night after a tough week, always a bad time to try to do anything). The poster jmull above basically wrote[1] what I was trying to say much more succinctly; this other post[2] is also more clear. Really I was just being snarky about the idea of shell scripting where you have to type 'await' in front of every command you want to run in a three-line file, like in the examples presented for this tool. 1. https://news.ycombinator.com/item?id=27080734 https://news.ycombinator.com/item?id=27080734 2. https://news.ycombinator.com/item?id=27077752 https://news.ycombinator.com/item?id=27077752

Raed667 5y ago

I wasn't attempting to defend JavaScript design choices. I'm just stating that working with blocking vs non-blocking code is now MUCH easier (and less error prone) since we have async/await. Callback-hell and Promise-hell were real issues that plagued any project of significant size.

trog 5y ago
Oh yeh sorry I didn't mean to give the impression I thought you were wrong. I 100% agree with you. I remember the first time I experienced "callback hell" (2016, for me, but I'm sure it was a huge problem for others before then) when I was doing some JavaScript stuff implementing Keybase's library for GPG support - I learned they'd built a whole separate JavaScript thing called IcedCoffeeScript[1] specifically to add await/defer support to get rid of those huge callback pyramids. 1. http://maxtaco.github.io/coffee-script/ http://maxtaco.github.io/coffee-script/

jmull 5y ago

I agree with this syntax, but it’s too late now (for JavaScript). To clarify, JavaScript could have made await the default for async functions, so that if you called an asynchronous function without putting any keyword in front of it, execution would block until the operation completed. In that design, there would be some keyword you would use when you did not want to wait. What they did: you have to opt-out of async execution by adding the await keyword. What they could have done: you opt-in to async execution by adding a keyword. They just chose the wrong default (IMO). It’s not a big deal — it’s easy enough to type “await” here and there. It’s bad, though, that you don’t really see the basic flow of control from examining the code making function calls. You also need to consult the function definitions to see which ones are async. Another option would be to have no default, and instead require that async functions be called with an explicit indication of whether they are to execute sync or async. That too heavy-handed, IMO. Fine for a statically checked language but not a dynamic one.

trog 5y ago
Thanks, this is basically what I was trying to say but is written so it actually makes sense.