> Your DNS example is a corner case One of the many corner cases that will kill your application or open it to DoS (malicious or not). I.e. you can DoS any no

> Your DNS example is a corner case One of the many corner cases that will kill your application or open it to DoS (malicious or not). I.e. you can DoS any nodejs application if * you can trigger it in making 4 DNS queries * and it does disk i/o (or uses any other core module using the thread pool) > There are discussions around it I've seen tickets opened since more than a year on this, without anything showing a willingness to improve that. Version 0.9 even removed the possibility to increase the number of thread (which they re-added in 0.10). > such issues impact all frameworks When you start using node, you don't expect that your bottleneck is a thread pool. In non async frameworks you know you'll have this kind of problems, you can design around it, and a DNS query in some module can't block I/Os for the whole application. > If you want to scale node, you would use multiple processes. By "unscalable" I meant libraries using O(n) or O(n^2) algos, with 'n' the number of users or the size of your data, where it would have been easy to do it in O(log) or O(1). > Promises not being in core is a good thing Why ? > Eventually many of those use cases will switch to using ES6 generators It hope it will improve, but we are discussing the current state of nodejs