Hacker News Reader

Comment by PopsiclePete | Hacker News Reader

The async/await model gaining traction makes me really sad. I use it all the time and it just seems like a giant hack, a band-aid to hide "scary complexity" from the developers. A typical Microsoft approach to things, but it should stay there.

First issue - the necessity for at least two of each method: "DoSomething" and "DoSomethingAsync". Weak. Now as a library developer, you just doubled your work. Sure, sometimes one method could wrap the other. But it's still weak sauce.

I much prefer the Go model - you only code "sync" API's, and let the consumer of your API wrap it in a go-routine and make it "async" if they wish. Much simpler, better, composable.

Async/await is also gaining traction in Javascript. Really, really sad we still try to avoid concurrent programming and how to do it right vs easy.

View on HN

I disagree. What you're arguing, in effect, is that async/await is bad because you should handle asynchronous APIs by taking a synchronous API and running it in a different thread, which experience has generally shown to be a recipe for buggy code, inefficient code, or most likely both.

The underlying idea behind async/await is that synchronous methods shouldn't exist in the first place--you'd only have the asynchronous API. Async/await enhances that model by turning the promises' functional interface (which requires interesting binding to handle loops/recursion) back into an imperative control interface.

Not true from what I've seen Every C# library with support for async/await has synchronous versions of those same methods. In fact, Microsoft's own documentation recommends appending "Async" to the method name for precisely that reason - to distinguish an async method from a sync method.

Furthermore, "asynchronous" code doesn't need separate threads. A scheduler and green threads is more than enough.

Have you seen Go? You should take a look at it. It makes writing concurrent code basically trivial, using "green" threads and channels and a neat little "select" statement.

They only support both because most libraries still support older version of .NET

If they were to support only .NET 4.5 or higher, then you can just call any async method in a sync manner simply by doing httpClient.GetAsync(...).Result

async/await in C# is a beautiful thing.

I like the idea of a way to make async code more readable but the execution of it in .net is very awkward, every async task is magically run on some threadpool and when the task is done your async function will also continue on that second thread. This means that code above the await and code below it doesn't run on the same thread, and there is no way to control it, this is just asking for trouble if you have other shared state. Shared state and threading is of course always trouble but with the async Task-library you hide it away, with explicit callbacks its easier to see where the entry points of second threads are and you can enclose them in critical sections.

However, in javascript the idea works because javascript is single threaded so you can be sure that the await-"callback" is always run when nothing else is. Explicitly defining some kind of message-pump that you can control the await-continuation yourself would be way around this in multi threaded languages but i haven't found a way to do so in c#.

It's trivial to wrap existing functions to make an async version.

    public Task<ReturnType> DoSomethingAsync(args) {
      return await Task.Run(() => DoSomething(args));
    }

In fact, it's so easy that I can think of at least two ways to automatically add async methods, either at compile time or at runtime. I would have to look into it a little more, but I think you could even write an extension method on object that would add the async version via reflection.

The upside of async/await is that you avoid callback hell. The code stays cleaner and is easier to read, both of which seem like wins to me.

That's a false choice you're presenting. "Callback hell" or "async/await". We have way more choices and opportunities.

Look at Go's CSP implementation, or Erlang's. No callback hell anywhere.

Right, but the languages that are looking at async/await weren't designed with that in mind. You could do a major overhaul of the language, or you could bolt on async/await. While Go/Erlang's way of doing things might be preferable to some, I'm not sure I see async/await as being bad enough to justify a major language overhaul.

With the world going multi-core more and more, the question that comes to my mind is - are the languages designed without concurrency in mind doomed to fail? It seems C++/C#/Java all look at concurrency/parallel programming as an afterthought - another library here, another library there, but none of them approach it as a fundamental programming necessity, on the same level as a basic loop or "if" statement.

Ultimately, it's possible to be semi-successful in designing scalable, concurrency-aware software with just after-thought libraries and language support, but is that really the way forward, long-term?

Reply on news.ycombinator.com