Live data from Hacker News

Async might be a fad

cs.oswego.edu

41–50 of 76 posts

Re: Async might be a fad

#41
post #13

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.

Or, sometimes you have to serve 10k pages at once. http://www.kegel.com/c10k.html

Re: Async might be a fad

#42

Earlier 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?

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

Re: Async might be a fad

#43

I'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.

See my blog post about a benchmark comparing the performance of heavyweight vs. lightweight Java threads in a web server: http://blog.paralleluniverse.co/2014/05/29/cascading-failure...

Re: Async might be a fad

#44

If 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.

> If 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.

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

#45
post #36

This 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.

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

Re: Async might be a fad

#46
Waaaaiit 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 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

#47

Seems 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.

Main author of Quasar here. The big question is what do "the majority of applications" tell us? A lot of applications run on virtualized hardware, which basically runs a few Pentiums on a single i7 box. So "the majority of applications" don't really need more than a Pentium. But is that really by choice? Or is that simply because modern hardware is so much harder to fully exploit, so we just don't bother and lower expectations? I think it is the latter. If we make it easier to fully take advantage of modern hardware (its processor and memory architecture, its IO/processing latency ratio etc.) then all of a sudden you'll see how most applications actually need every inch of performance they can get their hands on.

Re: Async might be a fad

#49
post #36

This 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.

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

How do you define "async" that excludes Go?

Re: Async might be a fad

#50

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

One-thread-per-connection is very bad. But one-thread-per-request is probably not that bad.
Post reply on HN