Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

I have gotten to the point where I just can't take seriously anyone who equates "the async style" to "Node's event based system" as if Go, Erlang, Scala, Clojure, etc. don't exist. No, you do not have to choose between speed and sacrifice a sane coding style, and anyone still pushing that Node propaganda is just not worth listening to.

Node is consistently beaten by multiple Go and Java frameworks across all benchmarks [1], consistently beaten by Scalatra, somewhat inconsistently beaten by the Haskell wai implementation (missing some benchmarks, I suspect wai would continue winning though if they were implemented; also I think those benchmarks are on an older Haskell IO manager). Not only are you choosing a dangerous coding style, you're not even winning the performance you think you are. Node is not faster. And certainly every library for Go, Haskell and Erlang, and probably everything for Scala and Clojure (not 100% sure of their runtime models) is already "async ready", and Java itself probably isn't exactly running short of libraries at this point.

[1]: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

Why is it a dangerous coding style? The new Node will have support for yield / generators that result in beautiful async code.

Of course, beauty is in the eye of the beholder, but I would say yield statements are not beautiful, they're just less ugly. Having lots of yield statements sprinkled throughout my code is (again, in my eyes) ugly. Less ugly than callback pyramids, but still ugly.

Try Go; get back to me on the beauty.

"Beautiful async code" is where the async is essentially invisible, because everything just is async.

It is indeed mind boggling when people list async (read: callback hell) as a feature. Complex systems rapidly get unmanageable, so people build nasty hacks to try to paper over the async core (it is still async single threaded at its core, run a dumb busy loop and watch your app stop responding).

Blocking is a feature. Blocking lets you reason easily, and as Go, Erlang, etc... have proven can be done at breathtaking speed and use all your cores... rather than wrapping your world view around async, use a system that allows you to keep your logic blocking and uses microprocesses to distribute work across a pool of threads. It is freeing to be able to just kick up 300k microprocesses if you need them.

Additionally, the node ecosystem tends to be quantity over quality... many of the available modules are simply more trouble than they are worth... while NPM makes getting them easy, it doesn't make deciding if something is worth using any easier.

What about generators and stuff like Koa[1]? Do you dismiss them too? You don't have to use events all the time, and it's trivial to wrap most Node IO as promises, thunks or whatever it is that you like, and then use generators as syntax sugar to work with them.

[1]: http://koajs.com

Still incredible hacks compared to a language that just does it right, you get composition problems with having so many techniques floating around that require adapters to work with each other, and you're still writing a ton of code that is simply paperwork, that the compiler could be doing instead. And it's nasty, error-prone paperwork too.

Remember, Node did not originate a single one of those techniques, despite what it sometimes sounds like. They're rediscovering them from the other communities that tried them, and subsequently discovered that the techniques did not solve their concurrency problems. Watching the Node community has been like watching the greater concurrency community's last 40 years compressed into 4 years; we are right on the verge of the inevitable recognition that these techniques won't save them either (I'm seeing the first traces of this in various blog posts), followed by an eventually dimming of Node's vitality as it slowly becomes clear that Javascript just can't do what Node is asking it to do, at scale. (Can not emphasize the "at scale" enough. Anything works on small cases. Node is good enough to work at medium cases, though the effort starts getting greater distressingly fast, which is only noticed by those who have worked in a saner environment. But it's just not going to work at scale any more than any of the other half-a-dozen virtually identical languages with virtually identical capabilities and virtually identical programmers.)

I agree, they should at least compare to Go.

However, it is fair to say that when using Java, you have to choose carefully since many API's block on I/O, including those that Java programmers use by default and are most likely to be familiar with.

The biggest impediment to async programming in Java-land is the lack of an async JDBC driver.

It's really not that hard to make thing run async / paralell in java: You just create a ExecutorService and submit your runnables / callables. The java.util.concurrent-package makes this easy, and google guava has some useful extensions as well (e.g. ListenableFuture). This approach does of course spawn new threads, but threads are lightweight and using a ExecutorService allows for pooling of the threads (ThreadPoolExecutor). I do this all the time, when I find parts of the code that's worth optimizing - e.g. fetching multiple objects from a distant db-server (like aws).

Reply on news.ycombinator.com