zhong-j-yu

7 ms·

1.
by zhong-j-yu 7y ago
I got hit by the bug just 10 minutes ago.
2.
In Defense of Service Locator(bayou.io)
2 points by zhong-j-yu 11y ago|0 comments
3.
by zhong-j-yu 11y ago
Are you judging a person based on his nationality?
4.
by zhong-j-yu 11y ago
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.
5.
by zhong-j-yu 11y ago
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 r
6.
Show HN: Jitpack.io – GitHub to maven, one less step in software publication(jitpack.io)
6 points by zhong-j-yu 11y ago|2 comments
7.
Async HttpClient for Java, from bayou.io(bayou.io)
1 points by zhong-j-yu 11y ago|0 comments
8.
by zhong-j-yu 12y ago
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 pro
9.
by zhong-j-yu 12y ago
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
10.
by zhong-j-yu 12y ago
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 `"!"`?
11.
by zhong-j-yu 12y ago
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 programm
12.
by zhong-j-yu 12y ago
One-thread-per-connection is very bad. But one-thread-per-request is probably not that bad.
13.
by zhong-j-yu 12y ago
That's a matter of terminology. I don't call `go` "async".
14.
by zhong-j-yu 12y ago
Because we have multiple app servers, but only one reverse-proxy? I don't want to centralize a task that could be distributed.
15.
by zhong-j-yu 12y ago
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.
16.
by zhong-j-yu 12y ago
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
17.
by zhong-j-yu 12y ago
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
18.
by zhong-j-yu 12y ago
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.
19.
by zhong-j-yu 12y ago
I would rather buffer the entire response in the app server, instead of in the central reverse-proxy.
20.
by zhong-j-yu 12y ago
I absolutely love Quasar. Nevertheless, there's an honest question whether it is actually needed in majority of applications. I think not.
21.
by zhong-j-yu 12y ago
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.
22.
by zhong-j-yu 12y ago
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 cautiou
23.
by zhong-j-yu 12y ago
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-
24.
by zhong-j-yu 12y ago
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 programmi
25.
by zhong-j-yu 12y ago
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 thread
26.
by zhong-j-yu 12y ago
Those are my thoughts; I'd like to hear counter arguments.
27.
Async might be a fad(cs.oswego.edu)
43 points by zhong-j-yu 12y ago|71 comments
28.
Comparing Java HTTP Servers' Latencies(bayou.io)
1 points by zhong-j-yu 12y ago|0 comments
29.
Should WebSocket Server API Be Event Based?(bayou.io)
1 points by zhong-j-yu 12y ago|0 comments
30.
Build HTML Trees in Java Code(bayou.io)
2 points by zhong-j-yu 12y ago|0 comments

More ›