4 ms·

> Things that used to be hard and are now easy: > Concurrency, with async/await (in several languages) The number of times I've been bitten by the very specif

> Things that used to be hard and are now easy: > Concurrency, with async/await (in several languages) The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it. Coming from the world of threads, I've found Kotlin's structured concurrency approach the best of the lot I've used so far, even if it isn't with out its quirks: https://kotlinlang.org/docs/composing-suspending-functions.html https://kotlinlang.org/docs/composing-suspending-functions.h...

tonyedgecombe 5y ago
Yes, the message was you could write asynchronous code as if you were writing synchronous code but that really isn't the case. It is easier but it isn't a panacea.
skulk 5y ago
> The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it. Got any examples? I've mucked around a fair bit with JS's async and never felt like it got in the way. (Other than the whole function coloring ordeal)
- ignoramous 5y ago
  > I've mucked around a fair bit with JS's async and never felt like it got in the way. When functions return more than one Promise, or when one chains async functions calls, it isn't really clear Errors from which functions are likely to break out and result in an unhandled exception (read also: https://archive.is/ULT7P https://archive.is/ULT7P). For example, does trapAllErrs() below trap 'em all? Not really. Why? The answer involves understanding the microtask queue and its place in the event loop. // traps all errors from a1 and a2, or so we hope async function trapAllErrs() { try { const p = Promise.all([a1(), a2()]) const results = await p } catch (err) {} } // sync code in a1 never throws async function a1() { // do something sync // ... // a3 and a4 may throw errs return Promise.any([a3(), a4()]) } // sync code in a2 may throw async function a2() { // do something sync // ... // a5 never throws const x = await a5() // ... return ans }
  - polishdude20 5y ago
    Would you do a .catch on the await p to fix that?
    - whoisthemachine 5y ago
      The solution to catch the errors for each function would be to catch errors from each promise individually (possibly within their functions, or within wrapper functions). This solution would also clearly state the intent. Performing concurrent tasks and only catching the errors at a higher level is a tricky thing to define behavior against; .Net/C# does it with the `AggregateException`, but even that comes with its own difficulties (which error comes from which promise? which came first? did one cause the other?).
  - zaccusl 5y ago
    I don't understand why this is complex? We know that Promise.all completes on the first error. That's literally the most basic knowledge of Promise.all (it either completes when all promises resolve, or rejects on the first error). You only need to understand basic JS to know why this doesn't work. You don't need to know anything about the microtask queue or event loop. Or am I missing something?
  - spoils19 5y ago
    Why not use Promise.allSettled...?
1ris 5y ago
Oh yes. I hate async/await so much. If I could uninvent one thing in programming it would be async/await. I wrote async/await code in C# for about a year. I did really try to learn it. I invested a lot of time. I did read Stephen Cleary. It often made sense for a split second only to fade away immediately. Usually the software would work, but i didn't understand what was going on in my own code. And others don't understand it either. Neither my code, nor the async/await concept. Stack overflow is filled with accepted answers that are just doing it wrong. This was part of the frustration. I did know enough to see that proposed idea was wrong, but didn't have a better idea. Most programmers don't even seem to understand that there is a difference between a C# Task<T> and a C++ Future<T>. I do. And it doesn't help one bit. My lack of understanding is not for lack of trying. I'm interested in different paradigms in programming. I'm eager to learn new things. While I'm programming OOP on the job, i learned Haskell [1], Idris and Prolog on my spare time. I mean, i can actually programm in these. I think esp. learning prolog shows I have some flexibility in thinking when it comes to programming. I would consider myself an above average programmer, compared to my colleges. But async/await is simply above my mental capacity. After 1 miserable year the of desperation with in C#, I quit my job and started a new C++ job in a new city. Life is good again. When this company adds async/await to their C++ (not yet in the language thankfully) I will quit again. I can't even describe what i don't understand about this concept, so far out is it. I only remember the purely practical anecdote that i could make a WPF command execute async but it was well-nigh impossible to make canexecute async. While completely absurd, the actually problems where way more conceptual. [1] Kind of ironic that everything in Haskell in async, i know. But it never got in the way there.
- Quikinterp 5y ago
  I hope someone can reply to this and help me learn more about async/await in c#. I'm finding it confusing too, and I can't put my finger on why.
  - 1ris 5y ago
    The only person that I trust to understand async/await is Stephen Cleary. He has a blog and written a book. Maybe try that. Official MSFT documentation became hand-waving or non-existent very quickly, back when i tried. Back then plenty other blog/tutorial/SO anwser on the internet has had fatal flaws such as making one thread per task or even mixing up the terms.

tonyedgecombe 5y ago

Yes, the message was you could write asynchronous code as if you were writing synchronous code but that really isn't the case. It is easier but it isn't a panacea.

skulk 5y ago

> The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it. Got any examples? I've mucked around a fair bit with JS's async and never felt like it got in the way. (Other than the whole function coloring ordeal)

ignoramous 5y ago
> I've mucked around a fair bit with JS's async and never felt like it got in the way. When functions return more than one Promise, or when one chains async functions calls, it isn't really clear Errors from which functions are likely to break out and result in an unhandled exception (read also: https://archive.is/ULT7P https://archive.is/ULT7P). For example, does trapAllErrs() below trap 'em all? Not really. Why? The answer involves understanding the microtask queue and its place in the event loop. // traps all errors from a1 and a2, or so we hope async function trapAllErrs() { try { const p = Promise.all([a1(), a2()]) const results = await p } catch (err) {} } // sync code in a1 never throws async function a1() { // do something sync // ... // a3 and a4 may throw errs return Promise.any([a3(), a4()]) } // sync code in a2 may throw async function a2() { // do something sync // ... // a5 never throws const x = await a5() // ... return ans }
- polishdude20 5y ago
  Would you do a .catch on the await p to fix that?
  - whoisthemachine 5y ago
    The solution to catch the errors for each function would be to catch errors from each promise individually (possibly within their functions, or within wrapper functions). This solution would also clearly state the intent. Performing concurrent tasks and only catching the errors at a higher level is a tricky thing to define behavior against; .Net/C# does it with the `AggregateException`, but even that comes with its own difficulties (which error comes from which promise? which came first? did one cause the other?).
- zaccusl 5y ago
  I don't understand why this is complex? We know that Promise.all completes on the first error. That's literally the most basic knowledge of Promise.all (it either completes when all promises resolve, or rejects on the first error). You only need to understand basic JS to know why this doesn't work. You don't need to know anything about the microtask queue or event loop. Or am I missing something?
- spoils19 5y ago
  Why not use Promise.allSettled...?

1ris 5y ago

Oh yes. I hate async/await so much. If I could uninvent one thing in programming it would be async/await. I wrote async/await code in C# for about a year. I did really try to learn it. I invested a lot of time. I did read Stephen Cleary. It often made sense for a split second only to fade away immediately. Usually the software would work, but i didn't understand what was going on in my own code. And others don't understand it either. Neither my code, nor the async/await concept. Stack overflow is filled with accepted answers that are just doing it wrong. This was part of the frustration. I did know enough to see that proposed idea was wrong, but didn't have a better idea. Most programmers don't even seem to understand that there is a difference between a C# Task<T> and a C++ Future<T>. I do. And it doesn't help one bit. My lack of understanding is not for lack of trying. I'm interested in different paradigms in programming. I'm eager to learn new things. While I'm programming OOP on the job, i learned Haskell [1], Idris and Prolog on my spare time. I mean, i can actually programm in these. I think esp. learning prolog shows I have some flexibility in thinking when it comes to programming. I would consider myself an above average programmer, compared to my colleges. But async/await is simply above my mental capacity. After 1 miserable year the of desperation with in C#, I quit my job and started a new C++ job in a new city. Life is good again. When this company adds async/await to their C++ (not yet in the language thankfully) I will quit again. I can't even describe what i don't understand about this concept, so far out is it. I only remember the purely practical anecdote that i could make a WPF command execute async but it was well-nigh impossible to make canexecute async. While completely absurd, the actually problems where way more conceptual. [1] Kind of ironic that everything in Haskell in async, i know. But it never got in the way there.

Quikinterp 5y ago
I hope someone can reply to this and help me learn more about async/await in c#. I'm finding it confusing too, and I can't put my finger on why.
- 1ris 5y ago
  The only person that I trust to understand async/await is Stephen Cleary. He has a blog and written a book. Maybe try that. Official MSFT documentation became hand-waving or non-existent very quickly, back when i tried. Back then plenty other blog/tutorial/SO anwser on the internet has had fatal flaws such as making one thread per task or even mixing up the terms.