Earlier quoted context omitted.
Maybe I'm looking at this from a different perspective. Some implementations do not require any response. For example if I have a honey pot that collects random events, the clients can just send the data to it without expecting a result (IE: I don't care if it's successful or not) and honey pot is not expected to write any sort of response. Clients send data and move on.
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.
Async might be a fad
41–50 of 76 posts
Re: Async might be a fad
#42Earlier quoted context omitted.
I would rather buffer the entire response in the app server, instead of in the central reverse-proxy.
Why buffer on the app server?
Re: Async might be a fad
#43I'm currently hacking on a toy webserver in Haskell, and from my point of view, I spin off a thread for each request, but Haskell's runtime environment manages all of these as a group of green threads doing aynch IO behind the scenes. Best of both worlds as far as I'm concerned. I just change serve request to forkIO (serve request) And magically I have multithreaded aynch IO that seems to be extremely performant.
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.
Re: Async might be a fad
#44If your application is largely fetching a bunch of external resources, say from something slow like a database or a web API, mashing them up and returning a response to a client, you need async. Node has a very beginner-friendly primitive for doing this.
Web request maybe, database definitely not. Async means you put a high load on the resource you connect to. In the context of a database that makes absolutely no sense. In fact, it's much more common that if you have an async app that you have a connection pool that gives out limited number of connections. At that point you might just use threads.
Re: Async might be a fad
#45This is a straw man argument. Async doesn't have to look like node.js' callback hell - that's what go, erlang and several other languages achieve with M:N green threading.
Re: Async might be a fad
#46And sorry anyone who wants to claim that Java's green threads are somehow a better programming model than async IO ala node.js + promises is pretending to write code. Yes async IO is not easy, certainly nowhere near as simple to manage as process / fork but with consistent coding style your can still end up with a system that behaves predicably and most importantly can be reasoned about.
Meanwhile I bitterly regret the days and weeks of my life lost to debugging threaded code. Never again!
Re: Async might be a fad
#47Seems like as a good a time as any to refresh people's ideas on Java. There is a user-thread implementation for Java. It does require instrumenting the bytecode, but it does work. http://docs.paralleluniverse.co/quasar/ . I'm looking at the port of Quasar to Clojure as my sole reason for looking at Clojure over Erlang.
I absolutely love Quasar. Nevertheless, there's an honest question whether it is actually needed in majority of applications. I think not.
Re: Async might be a fad
#48Re: Async might be a fad
#49Re: Async might be a fad
#50Waaaaiit a second! This "async thing" is not a fad created by node.js but rather the effective conclusion of the C10K problem - http://www.kegel.com/c10k.html - that we could scale up our application servers to handle more requests and that threads alone had failed to get us there. And sorry anyone who wants to claim that Java's green threads are somehow a better programming model than async IO ala node.js + promises…