* JavaScript wasn't the original language choice: he originally tried C, Lua and Haskell. He especially liked Lua but "it already had a lot of libraries written with blocking code."
* He regrets using the CommonJS module system. ("Far too complex and wildly different from how the browser works.")
Well, not as much as Haskell : "Haskell is pretty ideal but I’m not smart enough to hack the GHC. Lua is less ideal but a lovely language [...]" (at the beginning of the 2nd answer.)
> He regrets using the CommonJS module system
Yes, and this is pretty interesting. Also, he regrets using WAF as the build system ("it introduces more WTFs than necessary".)
I have a great respect for Ryan Dahl. He is not orthodox. He is not a blind parrot.
Actually, if he put as much effort into Erlang as he did into Node.js as of about six months ago, it would be a solved problem now. Some inspiration from Haskell could have proved useful, too; Haskell has finally gotten over the "strings are linked list of numbers" stupidity (amazing what being really concerned about performance will do for you) and are finally doing really interesting things with strings based on binaries.
The string type could be better, certainly, but the language has plenty of other aspects to make up for it. I hear Java is bad at {atoms,pattern matching,fault tolerance,...}.
I wrote a (somewhat limited) Lua asynch. webserver to provide a REST interface to my distributed filesystem, but I'm not interested in generalizing it or making it uber-scalable anymore. It uses select (luasocket.select, actually), which is quite good enough for my purposes. It's not the primary part of the system, anyway - it was actually feature creep.
The thing that really bugs me with node.js is writing everything in callback-passing-style. Coroutines are SO much cleaner.