@zhh-4096 在产业里，用行为（而非状态）建模是绝对主力的并发开发模式；基础构件是进程线程协程伪线程库或者过程对象；在这个模式下的race问题是被良好定义的，但是在实践上仍然有困难的地方，此其一；

其二，引入不确定性的因素太多，内核和任务的调度，过程间通讯，异步的i/o；在计算科学家里他们称之为hard to reason，放到工程实践上说就是易错难debug；

Node的单进程事件模型消除了内核和任务调度的不确定性和（伪）过程间通讯的不确定性，只剩下并发i/o带来的不确定性，它达不到（外部的）过去完全决定现在意义上的确定性，但是可以达到（外部的和通讯的）过去决定现在的确定性，这已经可以给设计、实现和调试都带来巨大收益；

其三，不管工程还是数学我们用组合方式构建复杂系统，构建过程中几乎是最重要的要求就是组合元素是可以保留基础元素的特性的，1+2=3，3需要和1或者2一样是正整数一样可以加法运算，这样这个游戏才可以继续下去；在非并发阻塞式编程中的函数，或者面向对象的对象，都具有这样的特性，组合的函数仍然是函数，组合的对象仍然是对象，但是把异步引入之后我们发现，这个特性玩儿不下去了，我们很容易对一个基础API说它是同步异步阻塞非阻塞，但是组合之后的结果就取决于运行路径了；

异步的问题有两个本质，一是对于通讯的异步它不可避免（Erlang作者JA说的那种异步），二是它本身就是事件模型的，不只是软件编程，CPU的流水线和乱序执行减少内存访问的阻塞等待都是一样的逻辑；

对于硬件设计单元来说它比较小，而且不是动态的；动态的意思是硬件不能动态创建一个CPU出来计算；但是软件上这是常态，而相关领域的研究严重滞后于产业实践，基于Process编程的理论，象今天大规模实践的CSP，在1978年提出，在80年代就完成了形式化；而动态输入输出状态机的形式化尝试，在过去一两年才出现；

上面说的这些可能或多或少有些抽象，我想强调的是异步本质是通讯，通讯本质就成了分布式，你把另一个进程或者线程放在本地还是远程执行只有性能差异没有模型差异；这里的水深到远超过程序员的数学水平能把模型做好的，象昨天有人转发的哪个用代数拓扑证明分布式和异步系统中的可计算性定理的，那特么就十万里都挑不出来一个程序员能看懂了。

但是这不意味着他们不重要，理论和模型永远是非常重要的。关于并发编程无论是产业和科学，都还刚刚开始，我们还在IBM 360系统刚刚面世，大家兴奋的在中断处理过程里写磁鼓磁带的调度器的阶段，还对一个OS Kernel如何建立，需要遵循多少设计规则，只有模糊认识，缺乏真正可靠易行的方法论和手段的阶段。