Hacker News Reader

Comment by halis | Hacker News Reader

I was never a fan of async/await in C#, I just never found it that useful.

I've seen examples of it in JavaScript and the author is always like, "Look at what you normally have to write and now look at what you COULD write with async and await!"

And it's like the same goddamn code with a few minor differences.

If they axed the whole proposal, I could get through this holiday season without even being depressed a little bit.

View on HN

The async/await example is much cleaner. I also think it's a great pattern for async code. It allows you to get away from callbacks altogether, and replaces those annoying conventions with "synchronous-like" code, which to me as someone who writes async code daily, is a god-send.

The amount of visual noise in the promise example cannot be understated.

You're getting downvoted because I don't believe you made a compelling argument against await / async. I do, however, fall into a similar line of thinking. For instance the code given was already poorly constructed so yes await / async will make poorly conceptualized code look better. But await / async forced an asynchronous behavior into synchronous meanwhile many other aspects of your application will be using asynchronous in the traditional sense. So it essentially mixes the two. This makes the code less maintainable, in my experience, because now you have code that haves the same but is structured in two very, very different ways that look like the traditional, blocking way of structuring code.

Due to this mixing I've seen many mistakes occur using await / async.

Yes because people screw up doesn't mean you don't include / create the feature. But at the same time I find the mixing of the two awkward and confusing at times.

I'm a huge fan of messaging patterns and async / await isn't really useful in a message based system so I don't have much of a dog in this fight.

You could say this for literally every single feature that got implemented in a language. Eventually a language needs to change and get better and it does it through small incremental changes as ES is doing. Future developers will only use await/async and they will look at old syntax/semantics and have the same attitude towards it that you have now towards async/await.

I find async/await in C# to be super useful, and fairly addictive once you start using it. Say you want to do three independent things in a function. How would you run them in parallel without async? Delegates, background workers, or threads? With async, this is simply done with Task.WhenAll().

Agreed, there are situations where it's super useful and I never want to go back to the old way.

I did read up on the paper that explains how the compiler rewrites the code before being comfortable using await.

Well, the runtime then runs the Tasks in a thread pool, so using Task.WhenAll is just a one more item to the list of options in that sense. It is a nice abstraction though.

What's wrong with threads and synchronizing? async I/O has its own level of complexity. But to be frank a better option is go-routines + channels + select construct like with go. That's really what makes both Go and Erlang unique.

I'm a fan of async/await in C#, but never use them. I've been deep into the bowels of callback hell and it's lame. Debugging other people's asynchronous state wrangling machines is also lame.

But I just don't write enough asynchronous code to actually benefit that much from async/await, and not all asynchronous patterns map nicely to the hierarchical nature of call graphs for me to take advantage of async/await all that sanely, as I found out from a few attempts to force the issue. And how do I add good debug visualizers to display tasks in flight? How do I serialize out long running async tasks? How do I modify things without breaking that serialization?

Reply on news.ycombinator.com