5 ms·

Your comment is ironic because C# implemented async in 2012. Async thinking takes a while to get used, but that doesn't mean it's more difficult than threads or

by nawitus 13y ago

Your comment is ironic because C# implemented async in 2012. Async thinking takes a while to get used, but that doesn't mean it's more difficult than threads or mutexes and whatnot. In fact, I think it's simpler. You don't have to learn anything properly new if you already know how functions work.

gfodor 13y ago
we haven't needed complicated threading on the web server for the last 20 years, because there is a natural isolation model that works most of the time: the request. node turns this on its head and says now you will need to think about concurrency always, even if you don't have a problem that naturally warrants it. that's the issue. if i want to write a goddamn shell script I need to think about concurrency. wat? are callbacks vs mutexes vs actors vs STM the best way to handle concurrency, that's debatable. but what's not debatable is that comparing concurrent vs non-concurrent code the latter is always easier for people to write and reason about, so you should tend to want to work in environments that are non-concurrent by default and let you focus just on the parts that you need to deal with concurrency.
- nawitus 13y ago
  Okay, now I understand your critique. I don't think it's a very good point though: Node.js is not designed for extremely simple synchronous web servers (and neither is JavaScript).
  - caoilte 13y ago
    That's a generational perspective. For developers fresh out of college promises, async, continuations and so forth are the norm now.
- macspoofing 13y ago
  Unfortunately, the traditional 'request' model ran into some practical scalability limits - colloquially referred to as the C10K problem. The problem is compounded by long-lived requests (comet-style push is still the best way to get around corporate firewall issues) which can block threads unnecessarily for long periods of time. We've largely solved this through async event-driven architectures and green threads. So no, things weren't always so rosy. By the way, one of the major benefits of Node is that it allows you to use the same libraries in your server and web-applications. So even without the scalability concerns, there would be good reasons to go with Node.
  - nightski 13y ago
    I'd say it paints a rosy picture for Node putting async event driven architectures on the same level as green threads. They are not even close. In one you have to manage all the details yourself, whereas the other results in a far cleaner implementation with much fewer opportunities for bugs.
  - gfodor 13y ago
    Did you read what I wrote? Yes, there are use-cases where the request->response model breaks down for web applications. I'll even admit that the set of applications where this is the case is increasing. But my point is that these are the exception to the rule, they are against the grain of the HTTP protocol anyway. The Node environment seems to have shifted from "use this for your one-off, high performance, I/O dominated real time service" to "hey, you know Javascript, build all your webapps in node, build your command line tools in node, build everything in node, since it's the lingua franca of the web." This latter trend sucks, and results in things that to me seem absolutely bonkers, like the Vows test framework.

by nawitus 13y ago

gfodor 13y ago

we haven't needed complicated threading on the web server for the last 20 years, because there is a natural isolation model that works most of the time: the request. node turns this on its head and says now you will need to think about concurrency always, even if you don't have a problem that naturally warrants it. that's the issue. if i want to write a goddamn shell script I need to think about concurrency. wat? are callbacks vs mutexes vs actors vs STM the best way to handle concurrency, that's debatable. but what's not debatable is that comparing concurrent vs non-concurrent code the latter is always easier for people to write and reason about, so you should tend to want to work in environments that are non-concurrent by default and let you focus just on the parts that you need to deal with concurrency.

nawitus 13y ago
Okay, now I understand your critique. I don't think it's a very good point though: Node.js is not designed for extremely simple synchronous web servers (and neither is JavaScript).
- caoilte 13y ago
  That's a generational perspective. For developers fresh out of college promises, async, continuations and so forth are the norm now.
macspoofing 13y ago
Unfortunately, the traditional 'request' model ran into some practical scalability limits - colloquially referred to as the C10K problem. The problem is compounded by long-lived requests (comet-style push is still the best way to get around corporate firewall issues) which can block threads unnecessarily for long periods of time. We've largely solved this through async event-driven architectures and green threads. So no, things weren't always so rosy. By the way, one of the major benefits of Node is that it allows you to use the same libraries in your server and web-applications. So even without the scalability concerns, there would be good reasons to go with Node.
- nightski 13y ago
  I'd say it paints a rosy picture for Node putting async event driven architectures on the same level as green threads. They are not even close. In one you have to manage all the details yourself, whereas the other results in a far cleaner implementation with much fewer opportunities for bugs.
- gfodor 13y ago
  Did you read what I wrote? Yes, there are use-cases where the request->response model breaks down for web applications. I'll even admit that the set of applications where this is the case is increasing. But my point is that these are the exception to the rule, they are against the grain of the HTTP protocol anyway. The Node environment seems to have shifted from "use this for your one-off, high performance, I/O dominated real time service" to "hey, you know Javascript, build all your webapps in node, build your command line tools in node, build everything in node, since it's the lingua franca of the web." This latter trend sucks, and results in things that to me seem absolutely bonkers, like the Vows test framework.