Async might be a fad

Post by [deleted] » Wed, Aug 06, 2014, 12:22 AM UTC

korzun wrote: post #58

zhong-j-yu wrote: post #30

Earlier quoted context omitted.

I agree, async is needed sometimes. Another example, a server broadcasts an event to multiple clients (e.g. a chat app), it would be silly to spawn a thread per client for that.

But the whole point of async is that, after data is dispatched the client moves on. I'm not sure what NodeJS does with it but this is my interpretation of the concept. I don't think people who know what they are doing, use async calls for mission critical operations. If async call returns response and client is required to read the response it's no longer considered non-blocking from technical perspective.

Post by [deleted] » Wed, Aug 06, 2014, 12:32 AM UTC

zhong-j-yu wrote: post #54

dragonwriter wrote: post #49

Earlier quoted context omitted.

How do you define "async" that excludes Go?

I use the word from the programmer's point of view; it's irrelevant how things are done under the hood. For example, in Go, when you read a value from a channel, it's just like a good old blocking call, as far as the programmer is concerned. On the other hand, an "async" read would involve callback, promise, or some other constructs.

Post by fleitz » Wed, Aug 06, 2014, 1:06 AM UTC

zhong-j-yu wrote: post #56

fleitz wrote: post #53

Earlier quoted context omitted.

I don't think you've seen truly great async support, it's virtually indistinguishable from sync code. Sync: let file = File.Open("foo.txt") let data = file.Read(8192) // Do some compute stuff with data ASync: let! file = File.OpenAsync("foo.txt") let! data = file.ReadAsync(8192) // Do some compute stuff with data

while the syntax can be as simple as that, there is still a difference, and the programmer still needs to be very careful. what if you accidentally forget the `"!"`?

Post by fleitz » Wed, Aug 06, 2014, 1:14 AM UTC

zhong-j-yu wrote: post #65

kaoD wrote: post #61

Earlier quoted context omitted.

> There is no problem to modify UI state from any thread; just put up some synchronizations. It reminded me of the "I know, I'll use regular expressions" joke.

The single-event-thread design is not without its own problem; programmers have difficulty in understanding and abiding to it too. Here we have an inherently concurrent problem - user actions and some IO actions occur concurrently. That problem cannot be reduced by some API or language trick.

Post by fleitz » Wed, Aug 06, 2014, 1:22 AM UTC

zhong-j-yu wrote: post #57

deadgrey19 wrote: post #51

I don't write web applications, and I don't use much JavaScript, so it's very possible that I don't properly understand the motivation for this blog post. However, as others have said there is a difference between some inconvenient syntax in JS, and the fundamental model of non-blocking I/O. What I do write is lots of C/C++ client/server applications for HPC/HFT/DC workloads where speed both in req/sec (throughput) a…

I apologize for the sensational and generalizing title. What I'm talking about is focused on web applications, and from empirical data, it seems that most web servers handle very few concurrent requests, therefore it would be silly to go all async to avoid threads. I'm very surprised that many people here argue that async code is much better to understand than sync code. Ok, so that part is subjective, and let's file…