
Best Practices for c# async/await - jonwagner
http://code.jonwagner.com/2012/09/06/best-practices-for-c-asyncawait/
======
eckyptang
I'm really not a fan of all the async stuff. Too much in the way of features
being strapped on the outside of the language now. It's turning into a feature
crapfest.

I'm moving away from the .net framework and ecosystem as well. It doesn't play
well with anything else and is becoming costly to keep up with the constant
framework churning.

We've got 60 people that need to get their head round each new feature.

~~~
wideroots
The constant framework churning? Examples?

I personally believe having a robust framework that constantly gets updates
and new features is a good sign for the development community. Just comparing
the changes happened in .NET to Java frameworks, I would to know how moving
away from the .NET is a better choice. Is there any other robust framework
that you are considering? I don't know any other frameworks that are robust
enough. Python and PHP certainly don't have the any comparable size of
"ecosystem" when compared to .NET. I use other frameworks when I have to, and
this usually happens when I'm developing mobile applications (Object-C for iOS
and Java for Android). So far, with changes in Azure, I'm pretty happy with
what .NET has done and where .NET is going.

Async/await is something I don't have too much experience, though. So far, I
don't think the feature wouldn't be too useful for a complex system and expect
the community to stick with how asynchronous programming has been done in the
past (e.g. Begin/End methods and IAsyncResults) for such system. However, I
think it's a really simple syntactic sugar that developers can take an
advantage when they are developing rather relatively small applications, such
as windows 8 apps.

~~~
upthedale
I agree, and I also take issue with the term 'churn'. Churn would imply that
features are being removed, replaced with these new ones.

What we are instead seeing is growth of the framework, and community.

To offer an alternative viewpoint to your later point, wideroots, I find the
TPL based Task Asyncronous Pattern introduced in .Net4 much more useful that
older patterns like Begin/End (APM) pattern, or the event-based pattern (EAP)
. I'm looking forward to using the new async/await keywords too. Some things I
could rewrite, some things will be better using the underlying tasks directly,
and for some things I use other supplementary async technologies, such as
Reactive Extensions (Rx) and TPL Dataflow.

But this is just an example of growth, not churn, as the older patterns are
still valid, and the community can choose.

As an anecdotal counterpoint to your last sentence, I'm not using these
technologies for small applications, rather the complete opposite end of the
spectrum. My observation is that the community is embracing these new tools.
But again, this is just an example of growth of the community, not churn.

