Erlang called, and left a message.
The message was "You are all super late to the party lol".
Async might be a fad
21–30 of 76 posts
Re: Async might be a fad
#22As 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://teep…
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.
Re: Async might be a fad
#23Seems 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
#24Some time ago I wrote my thoughts in a blog post:
https://idea.popcount.org/2013-09-05-it-aint-about-the-callb...
Basically, it's easy to show that callbacks are a much harder paradigm to work with considering flow control.
That's it. There is a place to use callbacks, but if you need anything that is not trivial and won't blow up at some point, you should use threads. Greenlets, processes or whatever you call it, things with stack that take time to context switch.
I strongly believe threads are better, if not anything else is due to the fact that when you do "spawn", you make an explicit statement, saying: here we demultiplex - programmer beware of flow control here!
Re: Async might be a fad
#25I hope somebody told the poster about putting a proxy server (squid, apache, nginx, varnish, etc.) between the application server and the client.
Proxy deals with slow client delays. App server serves app requests at speed. Tune number of proxy connections to keep app servers reasonably busy. Scale each layer individually.
IMO Whether the proxy is async or not is a matter of taste.
Re: Async might be a fad
#26As 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://teep…
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.
To be precise, threads suck because thread _scheduling_ is expensive. From a logical pov, structured programming still rules, and threads are an excellent way to implement structured programming.
Re: Async might be a fad
#27I hope somebody told the poster about putting a proxy server (squid, apache, nginx, varnish, etc.) between the application server and the client. Proxy deals with slow client delays. App server serves app requests at speed. Tune number of proxy connections to keep app servers reasonably busy. Scale each layer individually. IMO Whether the proxy is async or not is a matter of taste.
I would rather buffer the entire response in the app server, instead of in the central reverse-proxy.
Re: Async might be a fad
#28Earlier quoted context omitted.
Seems like you're looking at it solely from a web server/application back-end perspective. Async I/O and the corollary, freeing up threads, is useful in lots of other places like UI or applications that require very low latencies (We had a distributed process that had to respond to heart-beat requests from other machines amongst other I/O bound requests. Tying up threads when doing I/O would've been a death sentence)…
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 threads for handling concurrent requests in the blocking world; the question is whether this will result in too many threads, which depends on the application.
"My point is, move these IO actions to another thread; the code in that thread is good old synchronous/threaded code."
Sure. But how do you handle that? IO results need to be communicated back to the UI thread somehow.
Throwing together a whole new thread+stack against a named method that communicates back via explicit messages (or however you want to get the results of IO back to the UI thread) seems like a bit much if all you want to do is download a motd.txt and stuff it in a label.
Re: Async might be a fad
#29If 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.
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.
Re: Async might be a fad
#30Those 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.
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.