原标题：Deep inside Node.js with Ryan Dahl 翻译： JS堂 bbs.ajaxjs.com
出处：http://www.infoq.com/interviews/node-ryan-dahl
Q：你好 Ryan，请介绍一下你自己？
A：好。我叫 Ryan Dahl，工作在 Joyent，一间提供主机托管服务的公司。Node js 的作者是我，所以我猜这就是我在这儿接受采访的原因。
Q：起初，你开发 Node Js 的初衷是什么？那时候是想着打算解决怎么样的问题；然后你提出了怎样的方案去解决？
A：起初，我用 Ruby 服务器用得比较多。因为在于我的数学背景我常依靠 Ruby 来完成计算任务，渐渐也对 Ruby 发生浓厚的兴趣。但好景不长，在弄文件上传的时候我想为用户提供进度条，显示上传了多少，却发现这是一个非常难解决的问题——几乎搞得我快狂抓了。Web 浏览器有这样的数据要显示，它不单通过 DOM 访问，还要向 Web 服务器询问接收了几多数据然后回来更新 DOM。Mongrel 上就有类似模块来专门针对此问题。
我不知道，一般像 Apache 服务器下面的做法，做个进度条的模块要怎么做？而 Mongrel 的做法便让我感觉不错，因为它在 WebServer 中内嵌了动态语言，动态语言就是让人感觉做起来轻松。于是我想，这会不会是未来几年快速发展的一个方向，并且那就是我自己可以努力的方向——同时我觉得，现在 JavaScript 的“军备竞赛”不正是揭开序幕了吗？我也晓得，事件编程缝接起来会十分自然，虽然那还只是一种实验，可估计干起来该是很好的。
Q：看见有其它的 JS 服务端如 Ringo JS、AppEnginesJS 等等，它们大多都 JVM 上运行。Node js 与它们这些项目对比分析来说，最明显的区别在哪儿？
A：Node 运行于 V8，并非 JVM。它们这些 JS 服务端的项目，或多或少的还是继续采用传统的模式开发，比如就是你在 Ruby 或 Python 上面看到的那样子。嗯，没关系，我总喜欢拿人家 WebServer 作为原型例子去比较，从中获益良多。可当你准备，要把让服务器处理多个客户端请求的时候（高并发），背后究竟开启了多少线程来处理那些如此巨量的请求？Common JS 的邮件列表已着手定义服务端的 JavaScript 应该是怎么样子的了，如 Narwal、Ringo 或者以前叫别的名字的什么。Helma 和 G 便是它们其中的下一代。
服务端的 JavaScript 已经比比皆是了。但实际上差异却很大，我所指的当然是在 VM 方面。事实上JS是单独的、非多线程的语言环境，导致其非阻塞的方案真的与一般传统方法有所不同。Node 就依存在于这么一个状况环境。
Q：因为多数的服务端开发者不习惯于异步 API，你又怎么打算介绍 Node JS 这方面的知识点，诸如磁盘 IO 与数据交互，RESTful 服务等，都如何实现？
A：任何皆回调（Everything is callback）。按照传统的做法，如数据库的情景，写文件的情景，把文件从一处地方移动到别处地方，按说每一步骤都要一个接着完成一个来做。而在 Node 之中，你却不好这样做。你会浪费掉很多的时间在移动文件的过程中，因为访问磁盘这些都需要很多时间。Node 之中一切都是回调，不允许你只是坐在哪儿，一动不动等待你吩咐……你必须提供回调，所以 Node 里面相当多的匿名函数就是你指定某个回调获取响应。不过，我想开发人员会渐渐习惯这样的风格。 前端开发者也会很熟悉吧！？嗯，相信这会是 Node 主要吸引人的地方。事实上，人们都知道同步 XHR 的不好，因为会锁定 Web 页面。但若谈论服务端，不知道为什么理所当然会用同步的思维去写，比如请求数据库资料便是同步的，否则的话我也不清楚我的代码写到哪儿了……
Q：从你的幻灯片中，得知你在 JS 之前，曾经尝试过其它的语言，不过不知道，是不是 C 语系语法方面的原因或者 V8 本身优秀才会令你吸引上此类型开发？
A：以前深入过 Ruby，但最终是 VM 性能让我却之不恭，实在太慢了。每次你尝试让它快一点，却无奈地意识到：“好，罢了，干脆 C 写一个不好？” 甚至而且，你写 Ruby 的每一行码添加到程序中，都不期然地减慢服务器的速度，所以最终你不得不出动 C 来解决。唯这样自己才不郁闷。用 C 写服务器的时候可以允许写文件的 IO。很长的一段时间内渐渐使得我有这么一个想法：“假设我抽象好问题的某个部分，人们就可以借助 C 写出轻盈的 Web Server”。不过人们不喜欢在 C 里面写东西。而我的真正想法是让人们处于某种非阻塞的环境中开发，这样才是服务器的坦途——不必惊讶，非阻塞的“手法”乃在计算机系统各个要素中很常见的做法。于我而言很想用 Haskell 或其它接近 Haskell 的命令式的语言来实现。只要在接收 Socket 事件之时允许以字面化的方法或使用纯函数就可以了。
因为问题是，事件循环会引致于副作用的发生，若你对这些副作用无所谓的话，也很简单，只需要控制数据到一个别的函数来解决副作用就可以了。有的函数没有副作用，你只需要缓冲一下，然后退回到事件循环刷新内核。于是，由于有副作用，一切很难说，所以就要靠别的函数来搞定它。但是你从事件循环中接收事件你也可以纯功能的，你真的可以不受其他人的影响做好那件事，这样就不错了。但是你也去看那些非常难的 GHC，真的会放弃。自问我不是擅长哪方面的程序员。而后来 V8 出来这些难题都迎刃而解了。我最初不搞 JS 的，真的，一点也不搞，不过有次我在玩 VA 的时候感觉 JS 就是浑然天成了。
Q：听说你当初想用 Ruby 和 Haskell 做着实让我吃了一惊。通常认为 Node 卖点在于 JS 而你却澄清原来 JS 只是选择的方案非第一个重要的考量。
A：很难说那是不是重要的考量，我自己来说无甚所谓。然而拜 Google 所赐竟有如此不错的 VM 还是 BSD 许可的，它里头包含了很重要的东西在内。另外，JavaScript 它好就好在没有预设的 IO 库。当然我们说过有些东西怎么样怎么样，但是一般来说 JS 没附加上什么所以显得很纯。如果你说 Ruby，预设计好的话有条条框框的函数反而不好。
Lua 是我另外关注的语言，不过它也是有标准库的了。JS 只是纯粹的一门语言确实这十分好，好像数字和字符串和一些匿名函数都非常简单和干净。我想 Node 之所以受到那么多的关注在于本身是 JS 的，而且人们都有这么的想法，不希望他们的程序员在 JS 与 JVM 语言的上下文来回切换，反正这都是那么多的废话。另外，Node 之所以吸引人们还有一个原因，是因为使用起来这是一个小巧的语言。
Q：你看见人们所使用的 Node js 有哪些类型的？有哪些案例在发挥着 Node js 的作用？
A：现阶段解决的问题，就是针对小型的 Web Socket 服务端没有一个好的方案。诸如小游戏或者你有一批人在房间中走来走去，你必须关联于事件，在走路的时候要让别人知道，就会频繁地这样通讯着。之所以举聊天室这样的例子是因为现实中的确没有更好的办法来做。
我意思说，当然你也可以用不同的技术来做，恰好 Node.js 也是解决此类问题较好的方案。我想，Node 能够在不同的场合中应用，不但包括传统的如 Request、Response=Response-database 的网站，还可以是类似感知网络（Sensor Network）的网站。
