為什麼 WhatsApp 後台使用 Erlang 而不是 C?

01-27

剛看過報道它的後台是FreeBSD加上Erlang,請問這種構架有什麼好處？是否是一種創新和微信的構架比起來?

因為用 Erlang 寫起來容易。

先不說 Erlang 這種 single assignment 語言如何有效避免錯誤，光說並發支持、分散式通信的部分：

類似的任務，用 C 寫的話，之前 80% 的時間要用來寫一個和 Erlang/OTP 中用到的部分差不多的 runtime / library，才能再在上面寫業務代碼。

問題一：

為什麼選擇 AAAA 而不是 BBBB ?

像這類問題根本上都是技術選型問題。

考慮技術選型有以下幾點：

1. 創始人或者創始團隊對技術熟悉程度和偏好

比如有的習慣 C# 系，有的熟悉 Java 系，有的熟悉 Ruby or Python. 相對之下，他們會選擇自己熟悉的技術來實現。

2. 成本度量

從事任何創業活動，不能僅僅從技術角度考量，還要從運營角度考量。

能不能快速構建原型上線？(核心：出產品是關鍵)

能不能招到成熟可用的合適的技術人員？(當下：最大的成本是人力成本)

能不能面對快速迭代和需求變更？(你要明白：技術選型對產品的進化效率是有影響的)

3. 技術的現有基礎措施

該項技術的生態當下成熟不成熟？

有些哪成熟的第三方庫？

編碼和debug的支持如何？

該項技術的局限性會制約產品的發展么？

... ...

當你回答這些問題，答案就出來了。

在 WhatsApp 項目中僅以 Erlang 和 C 相比，Erlang 完爆 C.

------------------------------------------------------

問題二：

分析同上

------------------------------------------------------

問題三：

同創新沒啥關係。不用牽強附扯。

kiss原則，用最簡單、合適的方法。erlang在分散式處理和並發方面有著天然的優勢，c的成本要比erlang高很多，人家幾十個工程師就服務了幾億用戶，是微信的N分之一。

Erlang的協程併發模式簡單而清晰，語言本身天生就支持分布與並發，有成熟穩健的OTP架構可用。C/C++自身不支持協程必須用事件驅動方式才能應對大並發，而非阻塞方式對寫代碼的要求比較高。構建分散式並發架構顯然用Erlang/OTP要容易的多，當然如果你有一群牛逼的C/C++程序員且對OS以及網路通信等非常熟悉，開發出來的架構會更高效。