Go+ 可有效補全 Python 的不足
Python 的語法很靈活，融合了很多其他語言中令人覺得方便的特點。然而 Python 的優勢同時也隱含了其劣勢。螞蟻研究員王益在工業系統中對 Python 的親身體會，更加深刻地了解到了 Python 的局限，而 Go+ 是彌補方案里最靠譜的。那么 Python 有哪些不足?Go+ 又是如何能彌補的?本文分享王益對 Go+ 補全 Python 的局限上的相關看法和嘗試。
不久前許式偉(江湖人稱老許)的 Go+ 項目在 Hacker News 上掀起了一陣風潮[1]。我一見傾心，參與貢獻。最近老許和社區組織了一個視頻交流，拉我跟大家說說為啥關注 Go+ 以及圖個啥。在直播交流后，根據彈幕反饋，以及兩位好友 ——洪明勝(TenosrFlow Runtime 負責人)以及王玉(沈雕墨)的建議，做了修改。
我做分布式深度學習系統十三年了，尤其是 2016 年徐偉老師讓我接替他作為他原創的PaddlePaddle 項目的負責人之后，在工業系統中對 Python 的親身體會讓我對其局限了解愈深。而 Go+ 是我見過的彌補方案里最靠譜的。
我期待 Go+ 對標 Python，補全 Python 的不足，并且在此基礎上有一個類似 numpy 的項目(姑且稱之為 numgo+ 吧)用來支持張量(tensor)運算，滿足數據科學的需求;在 numgo+ 之上再構建一個類似 PyTorch 的深度學習基礎庫(姑且稱之為 GoTorch 吧)。如果可以，進一步成為深度學習編譯器生態的一種前端語言。
我現在在螞蟻集團工作，負責一個開源 SQL 編譯器 SQLFlow —— 把擴展語法以支持 AI 的 SQL 程序翻譯成 Python 程序。同事們說，如果 Go+ 這套生態能成熟起來，很樂意讓 SQLFlow 輸出 Go+ 程序。
很多讀者估計覺得我瞎說八道 —— Python 如此如日中天一般火熱的語言，何須“補足”?
Python 的優勢
Python 的語法很靈活，融合了其他很多語言令人覺得方便的特點。比如，和 C++ 一樣， Python 允許重載操作符，numpy 的作者于是重載了算數操作符來做張量運算。和 Lisp 一樣，Python 的 eval 函數遞歸地實現了 Python 解釋器，可以解釋執行 Python 表達式，所以 Python 程序可以生成自己。
這樣的靈活性允許程序員隨心所欲，因此特別適合探索性工作。比如研究生們用 Python 做科研;數據科學家們用來替代之前各種昂貴的商業化系統;在隨后誕生的深度學習領域，Python 也迅速蓬勃發展起來。
Python 的局限
Python 的優勢同時也隱含了其劣勢。 我親身感受的痛點有二。
難以保證代碼質量
語法靈活的另一種說法是：一個程序有多重寫法。現代軟件工程里沒有孤膽英雄，全靠大家合作。多種可能的寫法往往意味著團隊容易在 code review 時吵架 —— 而且難以平息，因為不一定有客觀選擇標準。很多其他語言也有類似問題，比如 Java。解法是，社區里定一些設計模式(design patterns)，程序員寫程序前先看看有沒有可以套用的設計模式，如果有，則遵循之。所以 Java 程序員除了學習 Java 語法，還要學習設計模式。C++ 也有類似的問題。解法之一是 Google 定了一套 code style —— 哪些語法可以用，哪些不許用 —— 按照 Rob Pike 的解釋，允許用的部分語法挑出來，就是 Go 的設計初衷。Python 太靈活，以至于 code style 都沒法定義得和 C++ 的一樣細致 —— PEP8 幾乎只是說說排版要求，對語法的選用幾乎沒有限制。Python 也沒法定義模式 —— 太多了，寫不完。
Python 為了靈活采用動態類型，所以我們看一個 Python 函數，必須得細讀其代碼，否則都不知道它有沒有返回值，以及返回值是啥。Python 也有語法擴展，要求編程者指明輸入輸出的數據類型，不過用的人不多 —— 畢竟大家都是沖著“靈活”來的;要是限制靈活性，那就真不如用靜態類型語言了。這個結果是，每個 Python 函數都不能太長，否則看不明白了。可是 Python 程序員就是沖著靈活性來的，要的就是信馬由韁的感覺，管你懂不懂呢，我自己明白就行，反正發完論文就畢業了。拆分函數細化粒度?不可能的，這輩子都不可能的。
有沒有寫的很好的 Python 代碼呢?有的。比如 Google Tangent。這是一個很小眾的項目。作者也只有兩個。其代碼結構清晰 —— 每個函數基本都在十行代碼之內，代碼和注釋一樣長，所以很好懂。不過這也和 Python 用戶眾多的印象相悖了。我在負責 PaddlePaddle 項目的時候，除了自己努力學習和總結 Python 的模式，也配置 CI 調用各種工具做源碼檢查，然并卵，這些工具沒有智能化到可以自動注釋代碼，也不會自動拆分太長的函數定義。
難以優化計算效率
Python 的語法豐富、靈活性強，所以解釋器寫起來很復雜，要優化性能也很難。相比之下，Go 語言語法簡潔，表達能力遠勝于 C 但是 keyword 總數少于 C，這種簡潔使得 Go 程序的性能優化比較容易。在 Go 誕生后幾年，Go 編譯器對代碼的性能優化水平就快速接近 GCC 對 C++ 程序的優化水平了，而 C++ 和 Python 一樣，語法豐富，所以編譯器里的代碼性能優化功能很不容易開發。
有人嘗試寫 Python 的編譯器來代替解釋器，從而在程序執行之前先做性能優化。但是 Python 語法比 C++ 更靈活，以至于幾乎沒法寫一個完全支持 Python 標準語法的編譯器出來。幾個嘗試因此作罷。目前的普遍的做法是解釋器來做執行時優化(JIT compilation)，因為有 runtime 信息，所以相對編譯器更容易一些。
在 AI 領域，深度學習訓練非常消耗計算資源。TensorFlow 的圖模式的解法是：用戶寫的 Python 程序在執行時并不真的做訓練，而是把訓練過程輸出成一個被稱為”計算圖“的數據結構，交給 TenosrFlow runtime 這個“解釋器”來執行。只要保證 TensorFlow runtime 的執行效率，即可不受 Python 解釋器效率的限制。
TensorFlow 圖模式用心良苦，也畫蛇添足 —— 源程序、各層 IR、以及 binary code 是一直以來人們用來描述計算過程的表達方式，TensorFlow 項目早年間發明的計算圖重復造了個輪子，而且造得不專業 —— 圖難以表達 if-else、循環、函數定義和調用，更別提 closure、coroutine 和 threading 這樣的高級控制流結構了。人工智能工程師的非專業編譯器設計讓 LLVM 的作者 Chris Lattener 掩面而笑，于是他嘗試用 Swift for TensorFlow 替換 Python 作為前端語言，用 MLIR 代替 TensorFlow 中的“計算圖” [2]。
補全局限的嘗試
我在負責 PaddlePaddle 期間為了驗證 Paddle Fluid 的能力，和我的同事陳曦一起做了一個無人駕駛船，嘗試用 Fluid 寫 immitation learning 方法，讓船能學習人類駕駛員的駕駛技術，詳情請見系列博客[3]。可是如果我們把跑 Python 程序的 MacBook Pro 帶上船則太費電，而嵌入式的設備上又不適合跑 Python 寫的訓練程序。如果每次停船后上傳數據到服務器訓練，那么船向人學習迭代的進度就太慢了。
為此，當時另一位同事楊楊寫了 Paddle Tape，用 C++ 實現了 PyTorch 的自動求導能力，結合 Paddle Fluid 積累的眾多用 C++ 寫的基本計算單元(operators)，Tape 完全是一個 C++ 實現的深度學習系統系統，和 Python 沒啥關系了。
2019 年初，我的朋友洪明勝在 Google 負責 Swift for TensorFlow 項目，這也是一個 AI 基礎架構去 Python 化的嘗試。他當時拉我給 Chris Lattener 的團隊分享了 Paddle Tape 和無人船的故事，并修改了幻燈片[4]。
我在螞蟻集團負責的一個開源分布式深度學習訓練系統 ElasticDL，嘗試過調用 TensorFlow graph mode、eager execution mode、PyTorch、和 Swift for TensorFlow，很受 Swift for TensorFlow 的設計理念以及和 Python 生態共榮的策略的啟發。
Go+ 和數據科學
以上嘗試提醒我，語言的選擇標準必須包括：語法清晰簡練和語法穩定容易學習。也希望語言的使用者是比較有探索精神的一個群體。Go+ 及其基于 Go 社區的用戶群體剛好符合這些條件。
在 Go+ 出現之前，也有把 Go 用于數據科學的嘗試，也有用 Go 實現的張量運算庫(比如 gonum)，但是用起來都不如用 numpy 的 Python 程序簡練，很直接的一個原因是 Go 的常量需要指定數據類型，而 Python 的則不用。我寫了幾個對比[5]。
用 Go 定義一個 ndarray 類型的常量，用戶需要寫：
- x :=numgo.NdArray(
- [][]float64{
- {1.0, 2.0, 3.0},
- {1.0, 2.0, 3.0}})
而用 Python 是：
- x = numpy.ndarray(
- [[1.0,2.0, 3.0],
- [1.0,2.0, 3.0]])
有了 Go+ 來自動推導數據類型，寫法就和 Python 幾乎一樣了：
- x :=numgo.NdArray(
- [[1.0, 2.0, 3.0],
- [1.0,2.0, 3.0]])
更進一步，老許加的一個 comment 解釋 Go+ 準備支持 MATLAB 的張量定義語法。這樣一來，這個程序就更簡單了：
- x :=numgo.NdArray(
- [1.0, 2.0, 3.0;
- 1.0, 2.0, 3.0])
類似的便捷的語法改進在 Go+ 已經積累了不少，例子在[6]。這些語法擴展足以極大簡化數據科學編程。
而 Go+ compiler 負責把利用這些語法糖寫作的 Go+ 程序翻譯成 Go 程序。這樣可以和其他 Go 語言寫的庫一起編譯，從而復用 Go 生態里的代碼。
復用 Go 生態是 Go+ 語言的一個長項。在 Go 的發展過程中，已經積累了不少科學計算的基礎技術，比如實現張量的 Go 數據類型的封裝。這些數據類型的計算也有高效的 Go 實現，部分緣于 Go 程序可以方便地調用 C/C++ 程序，包括科學計算領域里久經考驗的基礎庫如 LAPACK，甚至 NVIDIA GPU 的接口庫 CUDA。值得注意的是，這些基于 C/C++ 的基礎庫也是 Python 的數據科學生態的基礎，所以本文的標題是 Go+ 補全 Python 生態。
Go+ 和深度學習編譯器
上文提到了深度學習技術。這是 Python 被廣泛使用的另一個領域，和數據科學有自然的聯系，比如 PyTorch 和 TensorFlow 的 tensor 數據結構和 numpy 的 ndarray 一樣。而在深度學習領域，編譯器是最新的主流研究方向。
Go 社區里目前后臺系統開發者居多;視頻直播時，有聽眾在彈幕里說自己不是 AI 工程師，不關注 AI。如果真的這么想，恐怕不只是技術理想問題，而且是對飯碗不負責任了。
后臺系統和 AI 系統之間的界限越來越模糊，因為后臺系統指的是互聯網服務的后臺系統;而整個互聯網經濟建立在用不眠不休的服務器取代人來服務大眾，而 AI 是這個邏輯成立的基礎，詳見我的一篇老文[7]，例數了最近二十年被 AI 技術淘汰的人類職業。
而且這個界限在不久的將來會徹底消失，因為隨著 online learning、reinforcement learning、 imitation learning、federated learning 技術取代 sueprvised learning 成為互聯網智能(包括傳統的搜索、廣告、推薦，也包括新興的無人駕駛和金融智能)的主流技術，AI 系統將不再能被分為訓練和預測兩部分，也不再由 AI 工程師負責前者，而后臺工程師負責后者了。
在 AI 領域里，深度學習超越傳統機器學習的一個重要原因是：傳統機器的每一個模型(可以理解為對知識結構的描述)往往對應一種甚至多種訓練算法;而深度學習里，幾乎所有模型都用一種算法 stochastic gradient descend(SGD)或者其大同小異的變種來訓練。這樣，基礎架構工程師負責訓練系統的開發;模型研究人員復用之，大大減小了科研的工程負擔，提升了模型研發的效率。
深度學習系統的核心問題在于 autodiff，這是 SGD 算法的數學特點決定的。SGD 算法通過交替執行前向計算過程(forward pass)和反向計算過程(backward pass)，即可從訓練數據歸納出模型的參數。模型加參數就是知識。這里的工程挑戰在于模型研究者在定義模型的時候，就附帶描述了前向計算過程，但是反向計算過程很難由人來描述，最好有一個程序自動從前向計算過程推導出反向計算過程。這個自動推導被稱為 autodiff。
目前有兩種 autodiff 的策略。第一種在運行時推導，也被稱為 dynamic net 和 tape-based approach。基本思路是不管前向計算過程有多復雜，哪怕包括 if-else、循環、函數定義和調用、甚至 coroutine 和 multithreading，只要把依次執行的基本操作(operator)記錄下來，到一個 tape 里，那么反向計算過程就是回溯這個 tape 里的記錄，并且依次調用每個 operator 對應的求導數 operator(gradient operator)。這是 PyTorch、TensorFlow eager execution、以及 Paddle Tape 采用的策略。這種策略和編譯器關系不大，和 JIT compilation 有點關系。
另一種策略是運行之前推導反向計算過程，為此需要引入一個專門做 autodiff 的編譯器。TensorFlow graph mode、Caffe/Caffe2、Paddle Fluid、Google Tangent、Julia、Swift for TensorFlow 用的是這個策略。編譯器一般來說是把源語言描述的源程序翻譯成目標語言描述的目標程序。但是前三種技術偷懶了，沒有引入源語言，而是讓用戶通過調用 Python library 來描述前向計算過程。Google Tangent、Julia、Swift for TensorFlow 分別讓用戶用 Python 語言、Julia 語言、Swift 語言來定義函數，從而描述前向計算過程，并且能把前向計算函數翻譯成反向計算函數。
嚴格地說，Julia 的作者實現了多種 autodiff 方案：有運行時的、也有編譯時的、也有二者混合的。明勝在幫我修改此文時提醒：
For a different vision,where the same language is used to both implement kernels and construct+executeprograms/graphs based on the kernels, see [8].
這里的 kernel 指的是深度學習基本操作單元 operator 的實現。
編譯時和運行時 autodiff 這兩種策略，也都適用于 Go+，而且并不妨礙 Go+ 復用現有技術。就像數據科學領域應該復用 LAPACK 這些基礎庫，深度學習領域也應該復用基礎的 operators 和 gradient operators。
運行時用 tape 實現 autodiff 的策略的實現更簡單。我記得楊揚用一個星期時間就開發了 Paddle Tape。而編譯的策略復雜很多。Paddle Fluid 二十多人在 TensorFlow 團隊 Yuan Yu 老師的工作[9]的基礎上，用了好幾個月的時間，才搞定 if-else、循環、函數定義和調用的 autodiff。
這些嘗試提醒我們復用社區核心技術的重要性。比如，用 MLIR 代替計算圖從而能描述更復雜的控制流 —— 計算圖肯定沒法描述 goroutine 和 select。用 TVM 作為編譯器后段(backend)，用深度學習技術學習如何優化深度學習程序。所有這些技術的輸出，都是對基本 operaotor 的調用。從這個角度看，之前深度學習技術生態積累的 operators 類似 built-in functions。這也是洪明勝在修改此文時反復提醒的。
希望不久的將來，Go+ 可以作為一種新的深度學習前端語言，與 Python、Julia、Swift 并列，共同復用更底層的 IR、編譯器后段、以及基本 operators。
小結
我理解未來 Go+ 項目的核心戰術工作是：在維持 Go 的語法簡潔性的本色之上，合理準入簡化語法 —— 不要像 Python 和 C++ 那樣融入太多靈活性，同時在 Go 的極簡語法規范之上，適當地更加靈活。
此外，通過社區合作開發 numgo+ 和 GoTorch 這樣的探索性項目，豐富技術生態是社區的戰略方向。甚至更進一步，成為一種深度學習編譯器的前端語言，以復用多年來社區沉淀的深度學習底層計算技術。
最后，感謝老許和 Go+ 的核心貢獻者柴樹杉和陳東坡、Go 社區的杰出貢獻者 Asta Xie、以及我的同事 ONNX 社區核心貢獻者張科校閱。
相關鏈接
[1]https://news.ycombinator.com/item?id=23550042
[2]https://www.tensorflow.org/mlir/dialects
[3]https://zhuanlan.zhihu.com/p/38395601
[4]https://github.com/wangkuiyi/notes/tree/master/s4tf
[5]https://github.com/qiniu/goplus/issues/307
[6]https://github.com/qiniu/goplus/tree/master/tutorial
[7]https://zhuanlan.zhihu.com/p/19901967
[8]https://julialang.org/blog/2018/12/ml-language-compiler/
[9]https://arxiv.org/pdf/1805.01772.pdf
