I am unconvinced you are knowledgeable enough. "Contextual keyword" _does not_ mean "they don't have an impact on the IL". It means they are words _not reserved_ by c#, but instead have meaning only in certain contexts. You can otherwise use them as identifiers. `int await = 1;` will compile, for example.
58:30 This makes no sense. In a .Net Core WPF, you still need to do things on the UI thread. Or are you expected to use the Dispatcher for all the UI code in an async method?
4:30 "you don't want to block that operation". Yes, I do. I very much want to block these operations. This is because most of the time the rest of the program relies on successful storage or retrieval of this data. I've worked on numerous web applications, some of which are public facing, serving thousands of users at the same time. And never did I experience thread starvation or extreme lagginess because of those waits. Async await is nice for apps (actually was invented because MS wanted to create Windows Phone). But not needed for web applications. Complete overkill. Web applications are already asynchronous by nature.
Sorry, maybe I've missed your point, but the purpose of using async in a web app (as far as I get it) is to let the thread be used by other requests. And of course you will have all the data you need at the await point to do whatever you need to form a response.
Sad to see that in 2023 the author was not able to pick a better topic for his talk than the one that has already been covered dozens of times in books, articles, video courses etc. Disappointed 😿
It's knowledge and you are not chained in an underground dungeon told "watch it, or else..." I found it helpful in reminding me of something I forgot over the years.
I really like the approach of explaining the role of the Task class before explaining Async and Aeait
Really useful. Clears a lot of my concerns on using these asynchronous keywords and concept. Great talk, Filip. Cheers!
The joke at the beginning was great! 🤣
Regarding the statements on ConfigureAwait, does this mean we no longer need to add .ConfigureAwait(false) on "library code"?
Actually, we still do need it as our code can be used with a custom scheduler.
It's was good material, thanks for sharing!
I almost clicked away.
same 🤣
I actually clicked away but the second I hit the back arrow in my browser, he said it was a joke, so I restarted the video 😂
I clicked away after hearing C#, hoped for Rust
Same , was like wtf js 😂😂
Thank you for share your knowledge.
Awesome
Great talk!
Never mind me just bookmarking smthg. Avoiding deadlocks
44:00
the thing at 45:15 is verda debatable. the method is ignored if an exception happens and hidden in the stacktrace.
Did you just rick-roll the whole audience?
50:47 Streams
I am unconvinced you are knowledgeable enough. "Contextual keyword" _does not_ mean "they don't have an impact on the IL". It means they are words _not reserved_ by c#, but instead have meaning only in certain contexts. You can otherwise use them as identifiers. `int await = 1;` will compile, for example.
58:30 This makes no sense. In a .Net Core WPF, you still need to do things on the UI thread. Or are you expected to use the Dispatcher for all the UI code in an async method?
But isn't WPFs binding engine taking care about dispatching updates on the UI thread?
13:50 don't be fooled, while this may be funny now, reading code with bad naming conventions several days later will have you pulling your hairs out.
I wish he'd explained the generated code better.
Nice, but like other presentations, avoids practical stuff, like call async from constructor.
constructors cannot be asynchronous
I was about to stop the video after his first joke:)))
4:30 "you don't want to block that operation". Yes, I do. I very much want to block these operations. This is because most of the time the rest of the program relies on successful storage or retrieval of this data. I've worked on numerous web applications, some of which are public facing, serving thousands of users at the same time. And never did I experience thread starvation or extreme lagginess because of those waits. Async await is nice for apps (actually was invented because MS wanted to create Windows Phone). But not needed for web applications. Complete overkill. Web applications are already asynchronous by nature.
Sorry, maybe I've missed your point, but the purpose of using async in a web app (as far as I get it) is to let the thread be used by other requests. And of course you will have all the data you need at the await point to do whatever you need to form a response.
Sad to see that in 2023 the author was not able to pick a better topic for his talk than the one that has already been covered dozens of times in books, articles, video courses etc.
Disappointed 😿
It’s strange … isn’t it? Such an old topic.
It's knowledge and you are not chained in an underground dungeon told "watch it, or else..." I found it helpful in reminding me of something I forgot over the years.
Anyone who has to watch it inevitably falls asleep.
Who thinks it's great? Only the makers themselves.
Groan-