Erlang 之父 Joe Armstrong 逝世，如何评价他在计算机领域的贡献？

RIP, 哀悼，第一次由于名人去世而感到痛心。

Joe Armstrong 没必要说 erlang 与 OTP， 光他的论文《面对软件错误构建可靠的分布式系统》就足以载入史册——领先如今几十年，提出了OOP 等思想本质上不是并发的正确处理方法。

Joe Armstrong 在论文中是这样认为的：几乎全部传统的编程语言对真正的并发都缺少有力的支持——本质上是顺序化的，而语言的并发性都仅仅由底层操做系统而不是语言提供。

而用对并发提供良好支持的语言（也就是做者说的面向并发的语言 Concurrency Oriented Language） 来边写程序，则是至关容易的：

1. 从真实世界的活动中识别出真正的并发活动
2. 识别出并发活动之间的全部消息通道
3. 写下可以在不一样消息通道中流通的全部消息

程序的结构要严格保持与问题的结构一致，即每个 真实世界里的活动都严格映射到咱们编程语言中的一个并发进程上。若是从问题 到程序的映射比例为 1:1，咱们就说程序与问题是同构(isomorphic)的。映射比例为 1:1 这一点很是重要。由于这样可使得问题和解之间的概念隔阂最小化。若是比例不为 1:1，程序就会很快退化而变得难以理解。在使用非面向并发的编程语言来解决并发问题时，这种退化是很是常见的。在非面向并发的编程语言中，为了解决一个问题，一般要由同一个语言级的线程或进程来强制控制多个独立的活动，这就必然致使清晰性的损失，而且会使程序滋生复杂的、难以复现的错误。在分析问题时，咱们还必须为咱们的模型选择一个合适的粒度。好比，咱们 在编写一个即时通讯系统(instant messaging system)时，咱们使用每一个用户一 个进程的方式，而不是将用户身上的每个原子对应到一个进程。

其次， 经过定下的九条原则性思想设计，写出来自然支持分布式系统的 erlang 以及OTP框架，真的作到了他说的实现面向并发的语言（ Concurrency Oriented Language）。

• 一切皆进程
• 进程强隔离
• 进程的生成与销毁都是轻量的操做
• 消息传递是进程交互的惟一方式
• 每一个进程有惟一的名字
• 你若知道进程的名字，就能够向他发消息
• 进程之间不共享资源
• 错误处理非本地化
• 进程要么正常跑着，要么立刻挂掉

就以上九条的观念，设计出的 erlang 语言，成就了可靠性达到99.9999999%的目前世界上最复杂的 ATM 交换机。

其三，let it crash 思想的提出与实现。

程序不可能处理一切错误，所以程序员只要力所能及的处理显然易见的错误就行了，而那些隐藏着的，非直觉性的错误，就让他崩掉吧——原本就颇有多是极少见的错误，常常出现的？就须要程序员人工处理了，这是紧急状况，就算 try catch全部错误也没法避免，由于系统已经陷入崩溃边缘了，苟延残喘下去只是自欺欺人。

要注意的是let it crash ，并非说你用 golang，C++等语言打包个二进制，用 supervisorctl 等工具监控，错误就让他立刻崩，挂了自动重启 - = -，参考我以前的文章 应该如何理解 Erlang 的「任其崩溃」思想？

其四，一切进程都是轻量级的，均可以被监控（monitor），有Supervisor 专门作监控。

你能够方便的用一个进程（supervisor）去管理子进程，supervisor 会根据你设定的策略，来处理意外挂掉的子进程（这种状况很少的是，错误处理稍微作很差就会挂） ， 策略有：

• one_for_one：只重启挂掉的子进程
• one_for_all：有一个子进程挂了，重启全部子进程
• rest_for_one：在该挂掉的子进程 建立时间以后建立的子进程都会重启。

老夫敲代码就是一把梭！可不，只要重启就行。

实质上，这是有论文支持的：在复杂的产品系统中，几乎全部的故障和错误都是暂态的，对某个操做进行重试是一种不错地解决问题方法 ——Jim Gray 的论文中指出，使用这种方法处理暂态故障，系统的平均故障间隔时间 (MTBF) 提高了 4 倍。

所以，你就能够建立一课监控树，根节点就是啥事都不作，只负责监控的进程。其余都是它的子进程，若是不是 coredump（几乎不发生），那么根节点就不可能会挂；所以其余子进程就会正确的被处理。

固然，这有前提：5 秒内重启超于 3 次，就会再也不重启，让进程挂掉。为何呢？由于重启是为了让进程回到当初启动时的稳定态，既然稳定态都不稳定了，重复作重启是没有意义的，这时迫切须要人来处理。

---

Joe Armstrong 实在太多真知灼见了，好比 type system 才兴起不是好久，他就说，比起 完备且看起来完美的type system，更重要的是你如何去作这件事情，若是从一开始就考虑错了（如用了非并发式语言来处理并发问题），无论代码多正确，也不过是正确的走在错误的方向上。