3 ms·

JS has all sorts of problems, but I don't think being async by default is one of them. It's different, yes, but being async by default can be really useful for

by autarch 14y ago

JS has all sorts of problems, but I don't think being async by default is one of them. It's different, yes, but being async by default can be really useful for some tasks.

redidas 14y ago
I've never actually understood why the async thing is so hated. Spend some time in node, and you'll get used to it. A couple weeks ago I was writing a php script, and it actually felt awkward to query a database and then do something "immediately" after with the result. It isn't terrible, it's just different. And if you aren't used to it, it'll feel weird at first. This goes away with exposure and experience.
- andrewvc 14y ago
  My issue is definitely not familiarity. I've written more async code in more languages than most (node, java, ruby, clojure). My main takeaway is, unless I absolutely have to use async code I won't. It's almost never cleaner than queuing onto a thread-pool. In the case of highly parallel IO, yes, a thousand times yes async is great. But the great lie about node is that people need to carry over the async from the IO layer to the app logic layer. In node it's all just mashed together. For instance, the problem a websocket server is trying to solve is multiplexing M connections onto N available cores. Async works great for the connections layer, and a thread-pool well for the logic layer. The trick about async is that your server can handle 10,000 connections that are idle, but only a handful active at a given time since you only have a few cores. Thread scheduling works just fine. None of these ideas are novel, in fact, they are decades old. The real problem is the faddishness of ideas.
snprbob86 14y ago
It certainly can be really useful and thinking in terms of continuation passing style can be kinda fun and enlightening, but it's a pretty awful way to write code normally. I've used Node.js to good effect. It's a nice piece of software for a whole lot of reasons, but I think Go proves that there is a better way: http://golang.org/doc/effective_go.html#goroutines http://golang.org/doc/effective_go.html#goroutines

by autarch 14y ago

JS has all sorts of problems, but I don't think being async by default is one of them. It's different, yes, but being async by default can be really useful for some tasks.

redidas 14y ago

I've never actually understood why the async thing is so hated. Spend some time in node, and you'll get used to it. A couple weeks ago I was writing a php script, and it actually felt awkward to query a database and then do something "immediately" after with the result. It isn't terrible, it's just different. And if you aren't used to it, it'll feel weird at first. This goes away with exposure and experience.

andrewvc 14y ago
My issue is definitely not familiarity. I've written more async code in more languages than most (node, java, ruby, clojure). My main takeaway is, unless I absolutely have to use async code I won't. It's almost never cleaner than queuing onto a thread-pool. In the case of highly parallel IO, yes, a thousand times yes async is great. But the great lie about node is that people need to carry over the async from the IO layer to the app logic layer. In node it's all just mashed together. For instance, the problem a websocket server is trying to solve is multiplexing M connections onto N available cores. Async works great for the connections layer, and a thread-pool well for the logic layer. The trick about async is that your server can handle 10,000 connections that are idle, but only a handful active at a given time since you only have a few cores. Thread scheduling works just fine. None of these ideas are novel, in fact, they are decades old. The real problem is the faddishness of ideas.

snprbob86 14y ago

It certainly can be really useful and thinking in terms of continuation passing style can be kinda fun and enlightening, but it's a pretty awful way to write code normally. I've used Node.js to good effect. It's a nice piece of software for a whole lot of reasons, but I think Go proves that there is a better way: http://golang.org/doc/effective_go.html#goroutines http://golang.org/doc/effective_go.html#goroutines