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.

I don't use maven, but people ask for maven POM for my open source project (http://bayou.io), which makes sense.

So I read about maven; I read, and I read, ... still poop. It seems like a chore to publish to maven central repository. I'm lazy, and not the good kind of lazy, the lazy kind of lazy.

Fortunately there is https://jitpack.io/. Once you published your project on github, you've published it to maven world. That removes one step in the whole publication business which is already too messy.

It is great, I highly recommend it!

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.

One-thread-per-connection is very bad. But one-thread-per-request is probably not that bad.

That's a matter of terminology. I don't call `go` "async".

Because we have multiple app servers, but only one reverse-proxy? I don't want to centralize a task that could be distributed.

what I meant is whether it's a fad to spread async everywhere inside application code, and call that a good thing. the computer is of course async in nature; but the abstraction on the app layer does not have to be.

There is no problem to modify UI state from any thread; just put up some synchronizations.

The hard part is, if the modifications do not form a single, predictable, serialized chain, how can the programmer reason about them? This problem is independent of async/sync. If you use C# async for a UI action, you still need to worry about it.

I agree that external IO most likely would benefit from async. But, we don't need to turn the entire request-response code flow into async style, just because of one async call. We could break it up into 3 parts: sync code, async code (for external IO), sync code again.

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.

I would rather buffer the entire response in the app server, instead of in the central reverse-proxy.

I absolutely love Quasar. Nevertheless, there's an honest question whether it is actually needed in majority of applications. I think not.

We can argue that thread sucks because it is expensive. But we must measure how expensive it actually is in real world applications, before abandoning it. If a server must maintain a few hundred concurrent threads, it is really nothing.

That is where I disagree completely. I think the old fashioned sync/blocking/threaded style is much easier than async.

Of course, C# has great async support; but it is still a complicate thing that programmers must be very cautious about when applying.

Yes, even if your language/framework have great abstraction over async, it is still something that the programmer must be aware of, and must be reasoning about all the time. It's just easier doing sync instead, at least for the C-family programmers.

Yes, if you have light-weight threads, there's no question that threaded programming is better than async programming. But we are talking about heavy Java thread, and whether its cost is so high that we need to avoid threaded programming. I think the answer is no, generally.

Also, the discussion is in the context of imperative programming.

UI - of course the UI thread should not be blocked in handling IOs. My point is, move these IO actions to another thread; the code in that thread is good old synchronous/threaded code.

heart-beat - yes we'll need concurrent threads for handling concurrent requests in the blocking world; the question is whether this will result in too many threads, which depends on the application.

Those are my thoughts; I'd like to hear counter arguments.

Hi, I'm the author of the article, if you have any questions.