All in on async/await

While I haven't been coding in C# for about a year now I couldn't resist reading this recent article. A nice write-up where I only want to make two additions.

Go for C# developers: All your async are belong to us

Learning how to write "good" go code (in some definition of good) sometimes mean you need to unlearn old habits. This is especially true when it comes to asynchronous code if you have a C# background.

Asynchronous enumerations - again

Almost 2 years ago I wrote about this problem with accessing data from Azure and returning it in a LINQ friendly way. Well not long ago the discussion came up again only this time it was in regard to access data in a Cassandra cluster.

To await or not to await - that is the question

One question that comes up quite often is if you should always use async/await or not. Sadly enough the answer is not simple because there is a trade-off between performance and ease of understanding exceptions.

Don't let your constructor create the world around it

I recently listened to a developer podcast about the async/await feature in .Net. And I was terrified when the host asked about using those key words in the constructor.

Do you really want to properly implement TAP?

There is one part of implementing an API using TAP that I've always found cumbersome and that is the guideline to throw argument exceptions before the task is started. I've always been glad that I never had to make the call since I haven't been developing externally available libraries, but recently I had an interesting discussion at work that made me reevaluate my standpoint. Maybe...

Writing async tests

Ever since async/await was introduced in .net 4.5 I've seen people happily using those keywords in their (unit) tests. A usage I believe to be a mistake.

Logical task combinators

When I had to use Erlang for the very first time it was a brand new language and I was in collage. Back then Erlang did not have a logical not function so we had to define our own in order to make our code readable. At least given the knowledge me and my lab partner had at the time. So the other week I had a deja vu moment since I had a Task<bool> that I wanted to negate. At first it felt real weird and I ended up solving my problem in a different way. But then I started to think.

Unexpected Progress

When I was working on the WithProgress extensions I learned something about Progress<T> that I didn't expect.

Task-based Asynchronous pattern - for your pleasure

If you liked my old series of articles covering TAP and especially the different extension methods I showed. Then you will be even happier now.