Hacker News Reader

Comment by ignoramous | Hacker News Reader

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

View on HN

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.

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.

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.

If you don't know what a thread is, start there. Otherwise, you might read this.

https://blog.stephencleary.com/2013/11/there-is-no-thread.ht...

I think async/await is kind of a didactic mistake. It’s marketed as a way to not have to think about the underlying abstraction, but lack of the understanding about how it works under the hood will almost certainly bite you in this ass. This I find to be especially true when people are writing mixed async and sync code. The best way for me to learn was writing all of the code before the async/await sugar existed (scala in my case).

I think the intent is that you don't have any sync code at all.

Yeah but in practice it doesn’t work like that. There’s a ton of sync code that already exists and people know how to write sync code.

I have a pretty good mental model of it in JS and TS, because it builds on the pre-existing Promises API, because the transpilation process let me see the equivalent vanilla code while I was learning it, and because the event loop plus the single threaded nature of JS meant that libraries were already using asynchronous code everywhere.

When it comes to other implementations, though, I find them much harder to work with. In particular, existing synchronous or threaded code can block them, there's no good way to fix it without rewriting the synchronous code or shoving execution into a traditional thread, and all the existing libraries are synchronous. It feels like you need a completely new standard library to take advantage.

I've never had any trouble with async await in JS and Python. It's pretty close to being just like threading if everything were under one giant GIL.

It's just "Stop here and wait till the task finishes" and "Only one thing happens at a time and you don't go till someone stops".

If you quit rather than got fired, it seems like you must have learned async well enough to do your job.

I almost wonder if C/C++ et al aren't teaching people bad habits of thinking about how things work behind the scenes instead of just just trusting the language.

Haskell probably has the same effect, but it is also said to have some benefits too. It teaches people to look for underlying mathematical patterns in everything.

The thing with modern programming is it seems to be designed assuming you're thinking in terms of the language and libraries you are using at the moment, and building your architecture the way the language designers intended.

As soon as you try to actually understand how it works, or you try to get creative and do anything outside their opininated boxes, it gets ugly, otherwise it's usually fine.

You can't add async programming to a blocking language like Java or C#. It doesn't mix well, and will fragment the ecosystem with libraries that mustn't be used together.

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

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

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
   }

Would you do a .catch on the await p to fix that?

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

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?

Why not use Promise.allSettled...?

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.

Reply on news.ycombinator.com