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，更重要的是你如何去作這件事情，若是從一開始就考慮錯了（如用了非併發式語言來處理併發問題），無論代碼多正確，也不過是正確的走在錯誤的方向上。