Viewing profile — 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 stand…

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 see…

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 - u…

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 f…

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 g…

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…

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 chai…

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…

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…