3 ms·
It's trivial to wrap existing functions to make an async version. public Task<ReturnType> DoSomethingAsync(args) { return await Task.Run(() => DoSome
by tghw 11y ago
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.
- PopsiclePete 11y agoThat'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.
- tghw 11y agoRight, 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.
- PopsiclePete 11y agoWith 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?