4 ms·

Yes. People in general are really bad at grasping the concept that $programming_paradigm are not all equally suited for a given problem. Object Oriented, func

by nmjohn 12y ago

Yes. People in general are really bad at grasping the concept that $programming_paradigm are not all equally suited for a given problem. Object Oriented, functional, async, strict type system, etc. I've noticed an almost evangelical nature of people in trying to push their prefered environment on others. Guess what? Node.js is not the answer to everything (and I do 90% of my work in node!). But you know what? Neither is OO, or functional programming. There may be many advantages to your language of choice, but that doesn't mean it's always better. Fetching resources from many different areas - especially external or unpredictable (3rd party) services - that has async written all over it, and node makes that easy.

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 (for external IO), sync code again.
- orclev 12y ago
  In some code I wrote for a major corporation who will not be named, that's pretty much exactly what was done. We would use a thread pool to spin off a bunch of workers given Future instances to chew on, and then we'd just block waiting for all the results to come back before returning to the client. The thread that handled a request was synchronous to the client, but did all its services requests async and in parallel. Where appropriate we'd also chain things, so one batch of async requests would go out, the results would be gathered and then those results would be used to generate a new batch of async requests, which one again would be gathered and the results used to respond to the client. For those keeping track, this is basically the lazy IO pattern. Not async in the sense of nodejs (which I hate by the way), no callbacks, rather we get a collection of thunks which we can block on evaluating.

by nmjohn 12y ago

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 (for external IO), sync code again.

orclev 12y ago
In some code I wrote for a major corporation who will not be named, that's pretty much exactly what was done. We would use a thread pool to spin off a bunch of workers given Future instances to chew on, and then we'd just block waiting for all the results to come back before returning to the client. The thread that handled a request was synchronous to the client, but did all its services requests async and in parallel. Where appropriate we'd also chain things, so one batch of async requests would go out, the results would be gathered and then those results would be used to generate a new batch of async requests, which one again would be gathered and the results used to respond to the client. For those keeping track, this is basically the lazy IO pattern. Not async in the sense of nodejs (which I hate by the way), no callbacks, rather we get a collection of thunks which we can block on evaluating.