Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

JavaScript is definately a candidate, but I don't think it's going to be node.js. Doing all IO asynchronously strikes me as very premature optimization. I prefer the way Go or Erlang deal with these scaling issues.

View on HN

Funny you should consider async i/o to be premature optimization. To me it looks like the only reasonable way to build a non-trivial system.

Threads on the other hand, are the often the wrong optimisation -- processes are the right one.

The distinction of threads v processes is not something that necessarily influences the logic of our code. If I want to say a() b() c() I can do that with a thread or a process and it doesn't matter what a, b or c actually do. However, with the "IO must be asyc" stipulation, I have to know whether any of those functions is an IO call, because if it is, I have to write it in a completely different way, even if the logic I need is synchronous. I don't like that kind of interference with my logic.

Well, with very high probability, your logic is broken in the face of errors / malicious users then.

Node's async structure is just taking the async model of the web one step further, into processing the same request asynchronously if you need to wait for something else.

You might be master of doing this logic right, but I've audited tens (perhaps hundreds) of systems, and all the synchronous ones got it wrong.

(Disclaimer: I've never worked with Node. But I've been writing async servers in C and Python since 1999).

Node.js has synchronous, blocking IO options along with all the async ones. Just append Sync to the end wherever it makes sense.

Reply on news.ycombinator.com