Ryan Dahl addresses comments on his recent rant

I agreed with the general ideas in its original rant, but IMHO the problem is not the POSIX API nor the C language (including "volatile"), those are both well designed and simple stuff, for the most part (the C standard library is horrid unfortunately).<p>IMHO most of the problems are about the other layers: tricks you need to know about the operating system <i>implementation</i> of POSIX, or dynamic library loading, all the subtle things with different binaries formats, and so forth.<p>A few of this things are easy to solve, for me it is impossible to understand how the libC can be in this sad state, and how the replacements and improvements to it like glib are also a mess. If one day I'll not hack on Redis anymore my mission will be, assuming I'll have another way to pay my bills, to create a replacement for the C standard library.<p>While we are at it, not C++ nor Objective C are the final words on making C better and more comfortable to use (but I think the latter is much better than the former at it). This is surely an area where there is a lot to do. Unfortunately "D" is diverging so much form C that it should completely replacing it to get mainstream: very unlikely given the role C is playing today and the code base. A backward compatible improvement is still what we need I think.

<i>Can you not imagine a world where one could operate in native code without the concept of volatile variables?</i><p>Sometimes you want the compiler to do its best with register optimizations and code ordering etc and sometimes you have to explicitly tell it to go to memory every time. You could layer an abstraction over this but some people would still need to burrow under it. The point of working at the C/C++ systems layer is you have this control but also the responsibility that comes with it.

His first point here really hit home for me. Indeed, people like Ryan Dahl hate software for us so we don't have to.

"""We should program as if we were perched atop of 20 floors of bamboo scaffolding - because that's the state of the Unix userland."""<p>Genius.

POSIX is beautiful. d-bus != POSIX.

I wonder if perhaps he doesn't realize that Ted Dziuba is not a fan of Twisted either. He's generally recognized as a very belligerent, assertive personality, in the same vein as Zed Shaw, and you have to have a certain amount of thick skin when reading his commentary.<p>That said, the fact that Node doesn't provide the tools necessary to defer blocking JS code to a thread does pose a problem for these sorts of situations. Apparently (and correct me if I'm wrong; I'm not a Node expert!) Node won't let you run JS in any thread which is not the main thread. Twisted <i>does</i> let you run Python in non-main threads with the deferToThread()/callFromThread()[1] functionality.<p>I also agree with him about JS being a poor language for server-side work, but that's because I don't think JS's object model is well-suited to large, interface-driven/service-driven applications, and that isn't really a gripe with Node.<p>[1] <a href="http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorThreads.html" rel="nofollow">http://twistedmatrix.com/documents/current/api/twisted.inter...</a> and <a href="http://twistedmatrix.com/documents/current/api/twisted.internet.threads.html" rel="nofollow">http://twistedmatrix.com/documents/current/api/twisted.inter...</a> document threading in Twisted.