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