It seems like such a waste to use async libraries in many Java applications and I wince at the thought of a mainstream application framework adopting CPS. In the techempower benchmarks Netty beats Servlet by only like 3%. Maybe if you are serving millions of connections you will get your money's worth but I think a synchronous API in the application stack is the right answer for almost everything. Even Play framework with Scala which takes most of the edge off is still needlessly complex compared to say, Dropwizard code. You have to remember not to block, and be sure all your libraries don't block either. Why pick up that burden if it is not totally necessary?
Async might be a fad
11–20 of 76 posts
Re: Async might be a fad
#12I'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
#13Those are my thoughts; I'd like to hear counter arguments.
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.
Re: Async might be a fad
#14It seems like such a waste to use async libraries in many Java applications and I wince at the thought of a mainstream application framework adopting CPS. In the techempower benchmarks Netty beats Servlet by only like 3%. Maybe if you are serving millions of connections you will get your money's worth but I think a synchronous API in the application stack is the right answer for almost everything. Even Play framework…
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-family programmers.
Re: Async might be a fad
#15Seems 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.
Re: Async might be a fad
#16If 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.
Re: Async might be a fad
#17I'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.
Funnily, Java's original threads (back in 1997) were green threads, but they got dropped in favor of native threads.
Re: Async might be a fad
#18As others here have mentioned, there is no necessary relationship between the awful async syntax so common to JavaScript environments and non-blocking IO. There are plenty of languages/environments that support highly scalable network operations (that is, do not use a new thread or process to handle each new connection) without introducing callback hell.
The Greenhouse framework in Python is one of them (http://teepark.github.io/greenhouse/master/). The docs (linked) have a concise discussion of the various approaches to parallelizing IO operations with pros and cons of each, and, for most database applications, an obvious winner.
Re: Async might be a fad
#19I'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.
But there's no reason Java threads have to be heavy. Flip the question around: suppose you had a good syntax for nonblocking logic, and a library ecosystem where everything was async by default. In such a context (and we're getting there), why would you ever want to use traditional 4k threads? The only answers I can think of are for heavy number crunching and just maybe I/O on very fast dedicated devices.
So I think that's the future we're looking at: most code async, with the likes of LAPACK and some ultra-low-latency I/O libraries (hedge funds and the like) being the only users of traditional heavy threads.
Re: Async might be a fad
#20Async computation is not the fad, it's poor syntax is. C#, F# and coffeescript have excellent syntax that remove the line noise caused by writing async code. Actors and channels also nicely remove line noise from async programming. If anything as computers become more powerful and distributed you'll see threads and locks disappear rather than async computation. Async computation in an imperative style is what most wa…
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 cautious about when applying.