如何看待Facebook 的 HHVM 引擎將轉用 Hack 語言？

幾個月前一個朋友就透露了這個消息。 先下結論：Facebook 這樣做是對的。

Facebook 花了這麼大代價研發 HHVM，主要的目標是解決性能問題，但沒想到這麼快就被 PHP7 追上來了。如果僅僅從性能方面考慮，相信大部分人都會選擇 PHP7 ，那 HHVM 還有什麼存在的價值？

與其這樣不如反其道而行之，徹底拋棄 PHP 的歷史包袱，也許會獲得更大的空間。

PHP 語言有 20 多年的歷史，由於一直保持向下兼容。存在很多糟糕的地方，比如：

• 混亂的函數命名
• 不友好的 Array/String 函數，至今數組和字元串的操作都沒有實現 OO 介面
• 混亂的參數順序，導致完全記不住一個函數的用法，每次需要查手冊或藉助 IDE
• 難用的 Zend API ，導致了在應用與內核之間，很難有一個中間層。比如 Node.js 做的就很好，它提供的 C++ API 可以讓其他 C++ 程序員很方便地為 Node 編寫擴展模塊。而 Zend API 幾乎就是地獄模式，對開發者要求太高了。我在今年新開發的 PHP-X 就是為了解決這個問題
• 缺乏非同步 IO 網路層，PHP 官方只提供了 sockets、stream、select 等 IO 函數，無法滿足現在大並發時代的需求。所以就有了 Swoole 這個項目
• 缺乏對多線程的支持，雖然有一個 pthreads 項目，但這個連玩具都算不上。多線程需要 PHP 語言底層進行支持，而 PHP 設計之初就沒考慮過多線程

Hack 語言本身和 PHP 是非常接近的，PHP 轉為 Hack 也是一件很輕鬆的事情。未來 Hack 語言如果能夠完全解決這些問題，或許是一個更好的 PHP，就像 Python 2 和 Python 3 的關係。

PHP5性能弱，所以他們搞了hhvm，順便增強了PHP的語法，演化得到了Hack語言，然後他們遷移了大量PHP項目到了hack。後來PHP7來了，性能不輸hhvm，但是php7不支持hack，他們面臨兩個選擇，將hack遷移回PHP，或者繼續用hack和hhvm。hack有靜態類型和泛型等比較利於大項目的特性，最終他們選擇了hack，並不意外。

fb的行為，不值得模仿和借鑒，普通公司和普通人用PHP7更合適，hack是自找麻煩。

佈局來說, Facebook 想要有自己一套公開的語言。並且讓他有現行的價值。

日後要組個TensorFlow 可以用Hack,要有個Node.HH 的生態也可以, 要組個React Native 的通用機器層也可以用Hack

要怎麼怎麼都可以用Hack, 多爽啊

百度就慘了,Facebook的React協議風波,百度只能放棄React.

現在Facebook的HHVM又要轉向Hack放棄支持PHP,百度看來又要回滾到官方PHP7了.

挺諷刺的.

在腳本語言里,PHP7性能足夠優秀了.

PHP未來也會加入JIT,但個人認為,真要大幅提升PHP應用性能,離不開PHP+C的組合,典型的如Yaf和Swoole這些產品.Swoole不僅使用C實現引擎,而且還以不同於PHP-FPM的運行模式來運行服務,做到內存常駐,並且支持非同步編程,一個PHP Swoole工作進程就能輕鬆維持成千上萬個長連接.

Facebook這種規模的大公司,與其在Hack這種自創的冷門的不兼容原有PHP的腳本語言上投資,還不如考慮切換到官方PHP7+Swoole,適配Swoole的成本絕對要比用Hack重寫PHP應用輕鬆得多,而且Swoole能做到PHP邏輯內存常駐和非同步編程,這都是HHVM這個類似PHP-FPM的FastCGI服務所不具備的.

Facebook收購FriendFeed(Google員工創辦)拿到了Tornado這個Python里的非同步網路引擎和框架及其團隊,但最後並不是搞出一個類似Swoole的PHP非同步網路引擎,而是搞出了類似PHP-FPM的HHVM,這就太奇怪了.