Go 語言在工業(yè)上有非常多的應用，包括分布式系統(tǒng)和云計算平臺等。而 Go 語言并行性能高、部署方便和簡單便捷等特性令其在一些應用上超過了 Python，我們也曾討論過由 Python 轉向 Go 的 9 大原因。近日在 Go 語言的開發(fā)峰會上，谷歌發(fā)布了 Go 2 的設計草案，包括對泛型、錯誤處理和錯誤值語義等發(fā)展的討論。

在昨天的 Go contributor 年度峰會上，與會者對錯誤處理和泛型的設計草案有了一個初步的了解。Go 2 的開發(fā)項目是去年宣布的，今天谷歌公布了這一語言的更新。

欲快速了解相關內容，請看谷歌在 Gophercon 2018 上播放的視頻：
 

作為 Go 2 設計進程的一部分，谷歌發(fā)布了這些設計草案，以激發(fā)社區(qū)關于以下三個話題的討論：泛型(generics)、錯誤處理和錯誤值語義(error value semantics)。

這些設計草案不算 Go 提案流程意義上的提案。它們只是激發(fā)討論的引子，最終目的是給出足夠好的設計并將其轉變?yōu)閷嶋H提案。每種設計草案都附帶一個「問題概述」，其作用是：(1)提供語境;(2)為包含更多設計細節(jié)的實際設計文檔做準備;(3)推動關于設計框架和說明的討論。問題概述會提供背景、目標、非目標、設計約束、設計的簡要總結、對重點關注領域的簡短討論以及與先前方法的比較。

再次重申，這些只是設計草案，不是官方提案�，F(xiàn)在沒有相關提案事宜。谷歌希望 Go 的所有用戶都能夠幫助其改進草案并將草案完善為 Go 提案。為此，谷歌創(chuàng)建了一個 wiki 頁面來收集并組織關于每個話題的反饋。谷歌希望用戶幫助其更新這些頁面，包括添加用戶自己的反饋鏈接。

簡介

本概覽及附帶的細節(jié)草案是《Go 2 設計草案》(Go 2 Draft Designs)文檔的一部分。Go 2 的總體目標是為 Go 無法擴展到大型代碼庫和大量開發(fā)人員這一問題提供最重要的解決方式。

Go 編程無法成功擴展的一大原因在于錯誤檢查和錯誤處理代碼的編寫�？傮w來看，Go 編程代碼檢查錯誤太多，但處理這些錯誤的代碼卻非常不足(下文將給出解釋)。該設計草案旨在通過引入比當前慣用的「賦值和 if 語句」(assignment-and-if-statement)組合更輕量級的錯誤檢查語法來解決這個問題。

作為 Go 2 的一部分，谷歌還考慮對錯誤值的語義進行更改，這是一個單獨的關注點，但是本文檔僅涉及錯誤檢查和處理。

在 Go 開源之前，Go 團隊成員——尤其是 Ian Lance Taylor——就一直在研討「泛型」的可能設計(即參數(shù)多態(tài)，parametric polymorphism)。谷歌從 C++ 和 Java 的經驗中得知，這一話題非常豐富、復雜，要想考慮透徹并設計出一個良好的解決方案將花費很長時間。谷歌一開始并沒有嘗試這一做法，而是將時間花在了更直接適用于 Go 網絡系統(tǒng)軟件(現(xiàn)在的「云軟件」)這一初始目標的功能上，例如并發(fā)性、可擴展構建和低延遲垃圾收集。

Go 1 發(fā)布之后，谷歌繼續(xù)探索泛型的多種可能設計。2016 年 4 月，谷歌發(fā)布了這些早期設計(https://go.googlesource.com/proposal/+/master/design/15292-generics.md#)。作為 Go 2 再次進入「設計模式」的一部分，Go 團隊再次嘗試探索泛型的設計，希望泛型能與 Go 語言融合，為用戶提供足夠的靈活性和表達性。

在 2016 和 2017 年的 Go 用戶調查中，某種形式的泛型是最迫切的兩個功能需求之一(另一個是包管理)。Go 社區(qū)維護一份「Go 泛型討論摘要」(Summary of Go Generics Discussions)文檔。

許多人錯誤地以為 Go 團隊的立場是「Go 永遠不會有泛型」。但這并非事實，谷歌知道泛型的潛力，它能讓 Go 更加靈活、強大、復雜。如果要增加泛型，谷歌想在盡量不增加 Go 復雜度的前提下努力提高其靈活度，并使其更加強大。

錯誤處理：問題概覽

為了擴展至大型代碼庫，Go 程序必須是輕量級的，沒有不適當?shù)闹貜停�且具備穩(wěn)健性，能夠優(yōu)雅地處理出現(xiàn)的錯誤。

在 Go 的設計中，我們有意識地選擇使用顯性的錯誤結果和錯誤檢查。而 C 語言通常主要使用對隱性錯誤結果的顯性檢查，而很多語言(包括 C++、C#、Java 和 Python)中都出現(xiàn)的異常處理表示對隱性結果的隱性檢查。

目標

對于 Go 2，我們想使錯誤檢查更加輕量級，減少用于錯誤檢查的 Go 程序文本量。我們還想更加方便地寫處理錯誤的程序，提高編程人員處理錯誤的可能性。

錯誤檢查和錯誤處理必須是顯性的，即在程序文本中可見。我們不想重復異常處理的缺陷。

現(xiàn)有代碼必須能夠繼續(xù)運行，且和現(xiàn)在一樣有效。任何改變都必須能夠實現(xiàn)對現(xiàn)有代碼的互操作。

如前所述，該設計的目標不是改變或增強錯誤的語義。

錯誤值：問題概覽

大程序必須能夠以編程的方式測試錯誤和作出反應，還要報告這些錯誤。

由于錯誤值是實現(xiàn) error 接口的任意值，Go 程序中有四種測試特定錯誤的傳統(tǒng)方式。一，程序可以使用 sentinel error(如 io.EOF)測試它們的等價性。二，程序能夠使用 Type assertions 或 type switch 檢查錯誤實現(xiàn)類型。三，點對點檢查(如 os.IsNotExist)檢查特定種類的錯誤，進行有限的解包。四，由于當錯誤被封裝進額外的上下文中時，這些方法通常都不奏效，因此程序通常在 err.Error() 報告的錯誤文本中進行子字符串搜索。很明顯，最后一種方法最不可取，即使是在出現(xiàn)任意封裝的情況下，支持前三種方法更好。

目標

我們有兩個目標，分別對應兩個主要問題。一，我們想使檢查程序錯誤的過程更加簡單，出現(xiàn)的錯誤更少，從而改善錯誤處理和真實程序的穩(wěn)健性。二，我們想以標準格式打印出具備額外細節(jié)的錯誤。

任何解決方案必須能夠使現(xiàn)有代碼正常運行，且適合現(xiàn)有的源樹。尤其是，必須保留使用 error sentinel(如 io.ErrUnexpectedEOF)對比是否相等以及測試特定種類的錯誤這些概念。必須繼續(xù)支持現(xiàn)有的 error sentinel，現(xiàn)有代碼不必改變成返回不同錯誤類型。即擴展函數(shù)(如 os.IsPermission)來理解任意封裝而不是固定集是可行的。

在考慮打印額外錯誤細節(jié)的解決方案時，我們偏好于使用 golang.org/x/text/message 使定位和翻譯錯誤成為可能，或至少避免不可能。

包必須繼續(xù)輕松定義其錯誤類型。定義新的通用「真實錯誤實現(xiàn)」是不可接受的，且使用這種實現(xiàn)需要所有代碼。對錯誤實現(xiàn)添加很多額外要求也是不可接受的，這些錯誤實現(xiàn)只涉及到幾個包。錯誤還必須能夠高效創(chuàng)建。錯誤并非異常。在程序運行期間，生成、處理、丟棄錯誤都是很平常的事。

很多年前，谷歌一個用基于異常(exception-based)的語言寫的程序被發(fā)現(xiàn)一直生成異常。最后發(fā)現(xiàn)，深層嵌套堆棧上的函數(shù)嘗試打開文件路徑固定列表中的每個路徑去尋找配置文件。每個失敗的打開操作就會導致一個異常;異常的生成浪費了大量時間記錄這個深層執(zhí)行堆棧;之后調用器丟棄了所有這些工作，繼續(xù)進行循環(huán)。在 Go 代碼中錯誤的生成必須保持固定的開銷，不管堆棧深度或其他語境如何。(延遲的處理程序在堆棧解開之前運行也是由于同樣的原因：關心堆棧上下文的處理程序能夠檢查活躍的堆棧，無需昂貴的 snapshot 操作。)

泛型：問題概覽

為了推廣 Go 語言的大型代碼庫和開發(fā)者的貢獻，提高代碼的復用性就顯得非常重要。實際上，Go 語言早期的關注點只是確保能快速構建包含很多獨立軟件包的程序，因此代碼的復用成本并不是很高。Go 語言的關鍵特征之一是它的接口方式，這種方式同樣也直接定位于提高代碼復用性。具體來說，這種接口可以寫一個算法的抽象實現(xiàn)，從而消除不必要的細節(jié)。例如，container/heap 在 heap.Interface 操作上以普通函數(shù)的方式提供了堆維護(heap-maintenance)的算法，這使得 container/heap 適用于任何備用儲存，而不僅僅只是一些值。接口的這些屬性令 Go 非常強大。

與此同時，大多數(shù)希望獲取優(yōu)先級序列的編程器并不希望為算法實現(xiàn)底層存儲，然后再調用堆算法。這些編程器更愿意讓實現(xiàn)自行管理它的數(shù)組，但是 Go 不允許以 type-safe 的方式表達它。最接近的是創(chuàng)建 interface{} 值的優(yōu)先序列，并在獲取每一個元素后使用類型斷言。

多態(tài)變成不僅僅是數(shù)據(jù)容器。我們可能希望將許多通用算法實現(xiàn)為樸素的函數(shù)，它們能應用各種類型，但是我們現(xiàn)在在 Go 中寫的函數(shù)都只能應用于單個類型。泛型函數(shù)的示例可能為如下：

目標

谷歌的目標是通過帶有類型參數(shù)的參數(shù)多態(tài)性來解決 Go 語言庫的編寫問題，這些問題抽象出了不必要的類型細節(jié)(如上所述)。

除了預料之中的容器類型外，谷歌還希望能編寫有用的庫來操作任意的 map 和 channel 值，理想的方案是編寫能在 []byte 和 string 值上運算的多態(tài)函數(shù)。

允許其它類型的參數(shù)化并不是谷歌的目標，例如通過常數(shù)值進行參數(shù)化等。此外允許多態(tài)定義的專有化實現(xiàn)也不是目標，例如使用比特包裝(bit-packing)定義一個通用的 vector 和特定的 vector。

我們希望能從 C++和 Java 的泛型問題中學習經驗。為了支持軟件工程，Go 語言的泛型必須明確記錄對類型參數(shù)的約束，以作為調用者和實現(xiàn)之間的明確強制協(xié)議。但調用者不滿足這些約束或實現(xiàn)本身就超出了約束時，編譯器報告明確的錯誤也非常重要。

在沒有棘手的特殊情況和沒有暴露實現(xiàn)細節(jié)的前提下，Go 語言里的多態(tài)性必須平滑地適應到環(huán)境語言中。例如，將類型參數(shù)限制到機器表征為單個指針或單個詞匯的情況中是不可接受的。還有另一個例子，一旦以上考慮的通用 Keys(map[K]V) []K 函數(shù)被初始化為 K=int 和 V=String，它必須和手寫的非泛型函數(shù)在語義上同等地處理。特別是，它必須可分配給類型變量 func(map[int]string) []int。

Go 語言中的多態(tài)性應該要在編譯時和運行時實現(xiàn)，因此用于實現(xiàn)策略的決策還可以用于編譯器，并與其它任何編譯器優(yōu)化一視同仁。這種靈活性將解決泛型困境。Go 語言在很大程度上都是一種直觀且易于理解的語言，如果我們要添加多態(tài)性，就必須保留這一點。

參考內容：

https://go.googlesource.com/proposal/+/master/design/go2draft.md

https://news.ycombinator.com/item?id=17859963

標簽： Google isp 代碼 谷歌 開發(fā)者 搜索 推廣 網絡 云計算 云計算平臺

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。