4 ms·

I don't want to apologize for the existing callback-oriented APIs, because I agree it's easy to create some pretty hard-to-follow code in them. But there's som

I don't want to apologize for the existing callback-oriented APIs, because I agree it's easy to create some pretty hard-to-follow code in them. But there's something to be said for using non-blocking I/O calls. Threads aren't free, and spinning up a lot of them can tax system resources and impede performance. Allowing a number of execution contexts to share a single thread, automatically relinquishing control when they initiate an operation whose result won't be available for a while, can be a more efficient approach in certain circumstances. Given that, I do respect what Microsoft was trying to do with async/await in C#. I'm not convinced they were entirely successful, though. The sales pitch is that you can happily bang out asynchronous coroutines as if they were just sequential code, but the truth is that if you actually try to do that you're liable to run into some nasty bugs. I'm somewhat more intrigued by what some functional languages have done with the dreaded M-word to attack the same problem. The sales pitch is similar, but it's rather easier to deliver on the promise when "Just code like you normally do" being directed at someone who's normally writing in a functional rather than imperative style.

sergiosgc 12y ago
Python has achieved pretty much the same callback hell avoidance, without the need for monads or a foray into functional programming (in an imperative language). Python does it using generators as preemption points and using syntactic sugar for generator composition (yield from). The code looks rather nice, for async stuff: http://www.getoffmalawn.com/blog/playing-with-asyncio http://www.getoffmalawn.com/blog/playing-with-asyncio Using generators is rather clever. It's a look on generators not as fancy iterators that generate values but as fancy iterators that generate code execution steps.
- bunderbunder 12y ago
  Does it avoid the "Oops I accidentally forked a bunch of stuff I needed to run sequentially off into parallel threads that will now execute in an indeterminate order" situation? That's probably the biggest problem I see with C#'s async/await. Lovely syntax alone isn't sufficient, you need lovely syntax that doesn't make it it easier to write buggy code with the syntax than without. I suspect, though, (but cannot prove) that the risk of callback tangling an inevitable consequence of trying to slap this kind of abstraction on top of imperative programming style. The reason why I think success is more likely when functional languages try to do the same thing is the functional style itself: Explicitly passing your state around in arguments and return values rather than relying on side effects means that whenever you do need there to be a strict ordering among your callbacks, that will naturally express itself in the code.

sergiosgc 12y ago

Python has achieved pretty much the same callback hell avoidance, without the need for monads or a foray into functional programming (in an imperative language). Python does it using generators as preemption points and using syntactic sugar for generator composition (yield from). The code looks rather nice, for async stuff: http://www.getoffmalawn.com/blog/playing-with-asyncio http://www.getoffmalawn.com/blog/playing-with-asyncio Using generators is rather clever. It's a look on generators not as fancy iterators that generate values but as fancy iterators that generate code execution steps.

bunderbunder 12y ago
Does it avoid the "Oops I accidentally forked a bunch of stuff I needed to run sequentially off into parallel threads that will now execute in an indeterminate order" situation? That's probably the biggest problem I see with C#'s async/await. Lovely syntax alone isn't sufficient, you need lovely syntax that doesn't make it it easier to write buggy code with the syntax than without. I suspect, though, (but cannot prove) that the risk of callback tangling an inevitable consequence of trying to slap this kind of abstraction on top of imperative programming style. The reason why I think success is more likely when functional languages try to do the same thing is the functional style itself: Explicitly passing your state around in arguments and return values rather than relying on side effects means that whenever you do need there to be a strict ordering among your callbacks, that will naturally express itself in the code.