Best Practices for c# async/await | Hacker News Reader

Best Practices for c# async/await

code.jonwagner.com

106 pointsjonwagner9 comments

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.

Most of the new language features have been in the form of simple, predictable mechanical transforms that can be replaced with hand-written code in cases where you don't like them: enumerator functions, linq, and now async.

What don't you like about that? It's the perfect compromise: People who want syntactic sugar get it, but people who don't want the sugar are still free to utilize features that are designed for the sugar and interoperate with code that uses the features.

I don't like how the semantic boundary of the framework is creeping into the language. The language is complex as it stands and it's rather hard to get people who understand the entire language and framework and know when to use features and when not to.

The primary case is when people use the features they shouldn't do, which happens a lot on large codebases like ours regardless of the skill set of the people you employ.

If the language was extensible (as per LISP derivatives), I'd have less of a problem but it's a monolithic compiler.

Too much sugar is bad for your programmers.

I am currently sitting on the fence on this one. Once we start to use 4.5 and we have some face-to-code time on these async features then I'll make my decision.

However, at a first glance I must admit that I found these new syntactical additions confusing.

It is nice to hear what other .NET people are thinking though.

Out of interest, what are you using instead of .net? And what influenced your technology selection?

Copied from my other post:

Python + Pylons/Pyramid + SQLAlchemy + RabbitMQ + PostgreSQL + ReportLab all on top of OpenStack.

Influences: not too difficult to re-adjust to, all are open source, multiple vendors offering support, fits the dynamic model of our application, we have in house experience of all components, we can make them talk to our existing systems during any migration steps.

We're not doing a 1:1 switch - we're porting as we update features.

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.

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.

Examples: Windows Workflow (rewrites, drop of state machine model), AppFabric, Entity Framework (this is entirely volatile and unreliable), bugginess of MVC3 (attribute lifetimes, DI provider problems), Razor tooling (bugs, changes), IDE schizophrenia and unreliability, the mess that is MS11-100 (breaks every file download for us resulting in hours of work), Silverlight as a whole, ClickOnce being broken in IE9 (6 months for MS support to get us a fix).

I could go on. The whole thing is a dirty great minefield of crap. It's also entirely closed source which means you have to rely on the vendor to fix any problems, which we can't from experience, even though we pay them a fortune every year.

A robust framework is one that you can rely on to act consistently and reliably. It doesn't fulfill that requirement.

For the amount we're paying, we can afford to hire 5 new very senior guys in to fix any problems we have with open source software. That we can't do whilst we're paying for Microsoft.

Also, we feel screwed by the recent policy changes by Microsoft and do not want to end up in a walled garden or cloud service provider model which piggy backs of everyone else's work. Neither are a viable (or legal!) solution for what we do (high finance).

We're trialling various technologies at the moment. Python + Pylons/Pyramid + SQLAlchemy + RabbitMQ + PostgreSQL + ReportLab all on top of OpenStack is looking like the platform choice.

Azure doesn't have a SQL Azure instance that will fit 1/10th of our dataset.

Reply on news.ycombinator.com