zhong-j-yu

I got hit by the bug just 10 minutes ago.

Are you judging a person based on his nationality?

There's not much difference between government power and mob power. The end result is the same.

You'll be disappointed if you hold the general public to a higher intellectual standard.

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.

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 it under personal preference. For people who love synchronous coding but fear the cost of threads, I'm trying to make an argument that the fear is probably not justified.

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 `"!"`?

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.