Go語言的表達性、錯誤處理方法和泛型等討論摘錄 - 駭客新聞

Go語言表型力問題

paul_e_warner ：我已經用Go編寫了一些程式碼，而我遇到的主要問題是，對於一種“現代”語言而言，感覺真的已經過時了，每次使用它時，我都感覺像是在2005年與討厭的Java打交道。
Go語言可以在語言中新增一些功能，使其在不損害核心語言的簡單性的情況下，更具可讀性，並且更不易出錯。泛型是著名的例子，但真正令我關心的是缺少可為空的型別簽名。這是避免出現一整類錯誤的好方法，而我所使用的幾乎每種現代語言除Go以外都為此開發瞭解決方案。
我遇到的另一個問題是對反射。總的來說，我認為如果您必須依靠反射來做某事，那通常意味著您正在解決正常語言中的一些固有限制：所得到的程式碼通常比具有更高表現力的程式碼可讀性低得多。很多Go庫和框架在很多情況下都被迫使用它，因為沒有它，就沒有其他方法可以表達一些非常基本的東西。
我真的很想喜歡Go，我喜歡很多東西，它是“做某事的唯一方法”，這意味著程式碼總是感覺一致。將錯誤作為值是一種處理異常的優越方法。不久前，我不得不為求職面試專案寫一些東西，這確實令人耳目一新。

dcow：如果您是以自己編寫的原始程式碼量感到自豪的工程師型別，那麼Go是適合您的。如果您想專注於創造性地表達問題，那麼Go並不是您的工具。
在幾種不同的情況下，Go是首選語言。就我個人而言，Go太冗長了，在編寫確保程式碼正常執行所需的大量測試時，這尤其痛苦/明顯，因為Go的型別系統/編譯器不會幫助您確保程式碼正確性。

Go本質上是新的Java。

konart：我在處理js和ruby專案後的經驗（ruby是幾年前我的主要語言）：那些表達性強的語言導致的程式碼行數是減少了，但是最後，您遇到的是一堆垃圾，沒人願意修改，因為一些開發人員非常有創造力，他們想要表達自己的想法超過解決問題的能力。如果您確實想解決問題並確保以後的人們可以快速瞭解解決問題的方式和原因，那麼Go是一種工具。而不是對您的創作感到敬畏。

ratww：問題不在於表達性如何。Go的複雜功能很容易被濫用，並且在語言中沒有其他選擇。
Go中隨處可見：它允許反射和空介面周圍有很多“巧妙”之處，從而有效地將其轉變為規格不明確的動態語言。模板也一樣。這是與在Ruby中進行超程式設計的同一問題，也是困擾一些Java專案的複雜OOP體系結構的同一問題。當然，這都是可以避免的。
恰恰相反，這些功能不是“表達性的”，而是導致了一種“沒有人希望接觸的廢話堆，因為某些開發人員如此有創造力並想表達自己”的問題。
與高表達語言相比，使用Golang（或任何其他“非表達語言”）避免出現這種情況需要團隊付出更多的紀律。另一方面，許多新的ES6功能使它具有更高的表達能力，而不必增加複雜性，實際上使程式碼更易於閱讀和更可靠。

Philip-J-Fry：強烈反對：‘Go中隨處可見：它允許反射和空介面周圍有很多“巧妙”之處’，你可以透過反射來編寫聰明的程式碼。但是除非有解決問題的必要方法，否則我們不鼓勵這樣做，例如自動JSON編組/解組。沒有專業的Go開發人員會立即接觸空的介面或反射，而不用冗長的型別安全程式碼檢視解決方案的外觀。

dcow：當我談論表現力時，我指的是Lisp，Scheme，Rust，Haskell，Scala，Kotlin等。持續的注意力持續到他們必須編寫測試和部署程式碼為止。我的意思是，這正是Google喜歡Go的原因。但是我喜歡享受編寫程式碼的樂趣，並且理解我必須對其進行測試並在其整個生命週期內進行維護，所以我傾向於使用有趣且易於維護的語言。對我來說，那些語言傾向於提供正式的宏/超程式設計，型別系統，支援高階程式設計，並且最好執行記憶體安全性。我寧願讓大部分程式碼變得無聊，而更多地關注它是否在視覺上可讀並且在邏輯上易於理解。

amw-zero：Rust須是有史以來表達能力最低的語言之一，因此與其他實際表達語言一起使用時，這是一個很奇怪的語言。這並不是對Rust的全面否定，因為表達能力不是它的主要目標。
同樣，型別系統“健全”是一個非常空洞的願望。建立一個形式上合理但不實用的型別系統很容易。這與“型別正確性”相同。在Java具有泛型之前，Java程式是“型別正確的”，並且型別系統極為有限。
所以型別本質上是沒有意義的目標，因為型別可能意味著很多事情。

takeda：Ruby鼓勵人變得聰明，並且我有接觸過某人“聰明”程式碼的經驗。我對js不太熟悉，但感覺也與我相似。但是，使事情變得更糟的恰恰是它們都是動態語言，但是有一箇中間立場。舉例來說，Rust感覺（我仍在計劃學習它）看起來相比Java甚至C具有適當的功能。

candiodari：這其實就是ops運維和dev研發之間的傳統衝突。軟體研發人員想要一些小程式碼來表達很多東西，同時又要維護一些核心功能，除了不必顯式編寫程式碼外，研發人員實際上並不關心邊緣情況。不用說，無論研發人員多麼聰明，都會有一些極端的情況不是他們想要的。測試側重於核心功能，僅此而已。
ops運維程式設計師關注的是：應該讓一切正常執行。修改變成第二優先順序。他們會討厭任何他們不確切知道會發生什麼情況的極端情況，因為這可能很糟糕，這是他們所有工作的動力。他們想手動編碼每個邊緣情況，並進行測試。
C / C ++（特別是“智慧” C ++），Haskell，Lisp等適用於軟體研發人員。
Go，Java，C＃等適用於軟體運維人員。
一家大型銀行可能應該使用Java。嘗試創辦新銀行的人可能更喜歡Haskell。
我認為這種衝突不會很快解決，在軟體運維組織中引入變動，除了弄清楚軟體系統應如何更改之外，通常是一個挑戰。

noisy_boy ：我認為當談到Go的冗長性時，我們不應該指責Java。我可以簡單地在Java中執行dict.contains（“ foo”），而不必經歷冗長的迴圈：

    if val, ok := dict["foo"]; ok {
        //do something here
    }

collection.stream().filter(...).map(...).collect(...)

amw-zero：首先，Go的Map中可能存在或可能不存在值，這是一個普遍的問題。大多數語言僅返回nil或Option值，但是Go返回錯誤並強制您處理它。我沒有評論這是好是壞，但這就是程式碼之所以這樣的原因。
真正的問題是您剛剛弄清楚了程式碼就是那樣的原因，而且原因也很瘋狂。出於效能考慮，沒有一種語言會故意使某些細節變得冗長，以阻止這樣做。即使他們這樣做了，key查詢也是固定的複雜性，並且是您在所有程式設計中都可以執行的最有效的操作之一。
 dcow：Go的冗長性還存在某種可以幫助防止併發相關錯誤的記憶體安全系統（類似於Rust），那麼它的合理性就更高了。冗長而不具有強表達性沒有錯，強表達性這不是我的風格。
  

Go語言錯誤處理方式

fpoling：讓我為Go感到難過的是，冗長不是來自語言，而是來自其格式化程式。
如果如果err！= nil {return err}，如果格式化程式允許在一行中寫入，它將使程式碼行數減少三分之一。
不同意：將錯誤視為值是處理異常的一種非常優越的方法。我從未見過有力的理由解釋。我可以告訴您為什麼異常（用Java實現）很酷：您可以像成功執行每個函式一樣編寫程式碼，而不是在每個函式呼叫之後都新增一行（或更多）錯誤處理程式碼，這使操作更加困難遵循邏輯。

lolinder：我寫Java，但是我更喜歡將錯誤作為值，因為您不能只考慮幸福的道路。它確實使您考慮對這種特定故障的適當響應。您可以使用exception來做到這一點，但實際上，這就像您說的那樣：所有錯誤處理都委派給某個通用的包羅永珍的統一模組，在Web應用程式中，它通常只給出通用的500 Internal Server Error。
如果我將錯誤編碼為值（通常使用Either進行編碼），則在我在獲得成功的結果之前，必須決定如何優雅地回退是否發生了失敗。也許我只是隱藏了需要該資料的檢視部分；也許我顯示了適當的錯誤訊息；也許我透過電子郵件傳送操作，讓人們知道問題所在。無論我做什麼，我都必須認真考慮，而不僅僅是假設錯誤會被某人捕獲。當不可避免地發生故障時，結果通常會大大改善使用者體驗。
異常Exception往往使成本過高，以至於沒有上下文可以做出適當的決定。當您仍然有足夠的上下文時，值往往會迫使人們早日做出決定。

solatic：我不敢苟同：它迫使您考慮功能本身是否失敗了（但不是為什麼）。“為什麼”存在於錯誤（或異常Exception）本身的型別中，但是Go不會讓您檢查錯誤的型別。確實，純粹的人工記憶在大多數情況下會迫使您一次又一次地輸入err！= nil。
在Java程式碼中的每一行包裝在try / catch中（這不是慣用的，但絕對有可能），可以實現優雅回退。
如果像Go那樣返回錯誤“值”結果，那麼您也不應該直接將生產錯誤值向您的運營團隊傳送電子郵件。它無法縮放。您應該記錄該錯誤本身，並且您的監視裝置應面向負責更改的相關團隊（全面披露：我為這樣的監視堆疊公司工作）。您實際上很少想從錯誤中恢復，這種情況很少見，因為通常這是導致靜默故障並難以診斷問題的模式。

lolinder：是的，我不贊成Go的錯誤處理方法，而只是將錯誤視為價值的想法。我不能代表Go，但是其他語言非常明顯地表明，要處理錯誤，您必須檢查其型別，從而瞭解“為什麼”。
缺乏強制處理（型別檢查）異常的原因正是我不喜歡Java模型的原因。在檢查錯誤狀態之前，我想擁有一個可能包含或可能不包含我要查詢的資料的Either（如果沒有，請提供說明）。在真正異常的情況下，我可能會崩潰並給出500錯誤，但是根據定義，檢查的異常應該可以恢復，並且在生產程式碼庫中，我不想不從異常中恢復。

unscaled：在Java中，除了從RuntimeException派生的異常外，您必須捕獲或轉發所有異常，並且必須在型別簽名中指定它們。RuntimeExceptions等同於發生緊急情況，因此您不必catch它們。
Java從不讓您忽略非緊急的異常。與Go不同，您可以在其中忽略錯誤值。
除此之外，Java會強制您明確宣告每個函式可以引發什麼型別的異常。
Java異常比Go嚴格，反之亦然。
I/O異常子類之前都是來自於Exception異常處理的最佳實踐（就像最近在Go中引入了fmt.Errorf（“％w “））。
我同意Java標準庫（尤其是其中的較舊部分）是很糟糕的。Go標準庫，不管它有什麼問題，都還是很可靠的。
不幸的是，Java標準庫和Java EE庫的可疑質量在過去已經導致了我們今天在Java中看到的一些不良模式，而這種不良行為並不是該語言所必需的，例如嚴重濫用繼承。
我仍然要在這裡指出，返回錯誤值並不優於丟擲異常Excepton，因為：

1. Java異常處理也可以被強制為顯式的。
2. Go不強制處理錯誤。實際上，您始終可以忽略函式的返回值或將其錯誤部分分配。這遠沒有空白的catch塊明確。

puzz：檢視任何一段Java程式碼，並嘗試猜測其迴圈複雜性。這並不簡單。因為每一行和每個函式呼叫都可能失敗。而這種失敗是程式碼執行樹分支的另一個地方。除非您檢查程式碼中的每個方法呼叫，否則您將看不到它。
在Go中：每個錯誤都是顯而易見的，並且只要快速地進行處理，您就可以感覺到任何程式碼的迴圈複雜性。
所以，僅此而已。程式碼的複雜性是可見的。

tacitusarc：我認為解釋起來有些複雜，但主要歸結為：錯誤是真實的。Java方法讓您可以透過宣告異常來忽略它們，這種想法是，其他人會處理它。Golang函式使錯誤更加嚴重。他們迫使您考慮如何處理錯誤，並質疑您是否應該在特定情況下出錯。實際上，它幫助改變了我對功能的看法。在Java中，有很多行為情況我沒有顧及到過，但在golang中，使它們成為冪等既容易，而且事實證明，它更健壯。
引入的用於處理golang的錯誤處理模式雖然很冗長，但是確實可以使人們確信，一旦編寫了程式碼，就應該處理錯誤。當然，程式設計師可以顯式地忽略錯誤，但是這樣做與忘記捕獲引發的異常不同，因為程式設計師必須不遺餘力地編寫程式碼來忽略錯誤。

fierro：Go的基本宗旨是應對每個錯誤。以下是戴夫·切尼（Dave Cheney）的摘錄，澄清了這一點：
“對於真正異常的情況，那些代表不可恢復的程式設計錯誤（例如索引超出範圍）或無法恢復的環境問題（例如堆疊用完）的情況，我們會感到恐慌。”對於所有其他情況，按照這個定義，您在Go程式中遇到的任何錯誤情況都不是異常的，您希望得到它們，因為無論返回布林值、錯誤還是驚慌，它都是在您的測試中產生的結果程式碼。

lolinder：我認為關鍵是在Go中，您會期望失敗。失敗不是異常，它是邏輯的第一部分。
Java會限制您將失敗視為規則的異常，並將成功路徑視為實際程式碼。此後，我們很多人觀察到，失敗方法會導致錯誤，因為程式設計師會忽略失敗，從而使它們可以由堆疊頂部的“包羅永珍”來處理，這通常只是轉儲一個堆疊跟蹤並每天呼叫它。
Go所支援的範例將錯誤視為另一種程式狀態，而錯誤的含義與期望的行為同樣重要。這迫使程式設計師考慮失敗的所有含義，而不僅僅是新增另一個“ throws”子句。
 

Go vs. Java

ferdowsi ：我率先在公司建立了一個新的Go服務。如果是Node或Python，我很容易想到一個團隊陷入了數週的API框架，測試框架，整理工具，格式化工具，TLS堆疊，包裝和發行研究高峰等問題。使用Go，所有這些問題基本上都可以透過標準庫的強大功能來解決。我們再快樂不過了。人們常常低估了Go的聯網能力。使用標準庫中的伺服器，路由器，多路複用器，身份驗證等內容構建Web應用程式，然後僅在雲中部署二進位制Blob（與體系結構無關）即可使您的應用程式比競爭對手的程式語言/框架更輕鬆地執行。

takeda：我認為擁有選擇權只是成熟語言的標誌。在python中，您還可以實現API框架，使用標準庫進行單元測試，TLS和打包。同樣，Go也有3rd party框架。

loopz：可以肯定，總會有權衡取捨。許多人試圖傳達的是，Go的預設設定往往是更強大，更簡單的選擇。
但是，對於一個孤獨的狼性專案，我將更多地依賴於gorm之類的東西，而不僅僅是手工製作並維護大量的sql。
另一個誤解是，這些都是針對沒有經驗的程式設計師的。但是您需要數十年的經驗才能欣賞Go中已經進行的所有考慮到的權衡取捨。
不過，它只是一個工具，與FP完全不同，它完全是另一種野獸。很明顯，Haskell啟發了Go和生態系統的許多功能。從另一端看，這可能是另一個很好的工具。

boyter：我之所以使用Java是因為它足夠快，具有良好的庫並且具有足夠的生產力。Go的執行速度幾乎一樣快，標準庫滿足了您的大部分需求，並且它可以編譯為單個二進位制檔案的功能使部署變得簡單。
我也回頭想想，我可以用Java完成所有這些工作嗎？可能...但是我也覺得這需要更多的努力。

stickfigure：Java已經走了很長一段路。如今，以Java的函式風格進行程式設計非常容易。Go似乎竭盡全力使其變得更困難。也許泛型會有所幫助。Go更多地涉及顯式命令樣式，預設為良好/已知的效能特徵。建議不要嘗試使用FP，除非只是為了對其進行測試。

byronr：Go和Java是近親。當然，區別在於JIT：使用Go單個二進位制檔案意味著您可以將其分解以找出其要執行的操作。JIT增加了一層神秘感。另外，使用Go可以在效能熱點中避免堆分配。對於Java，我不太確定。

unscaled：透過JMH執行程式碼仍然很容易看到如何對程式碼進行JIT。像IntelliJ這樣的JVM和IDE包含大量的工具來進行審查。根據我的親身經歷，讓我們回到當前的問題上，如果您有許多小型變數，那麼您的應用程式在Java中的效能將比Go更好。Java中的轉義分析可能比Go中的轉義分析更高階，並且在Java中，如果您更喜歡吞吐量而不是延遲，那麼還可以使用分代generational  GC。

byronr：從本質上講-jar檔案並沒有定義將要執行的程式。它是jar和執行它的JVM的結合。使用Go，二進位制就是全部。因此，即使我可以預測特定的JVM將如何處理給定的jar，但是如果我的程式碼可能跨多個JVM部署，我仍然會陷入困境。
 

泛型的用處

strken ：沒有泛型的問題是您構建的系統問題。他們要麼放棄型別安全性，要麼使用反射，導致難以除錯的問題，或者依靠程式碼生成，這又慢又難以除錯。
我同意缺少泛型只會偶爾並不會像預期的那樣對生產率產生太大的影響，但是我仍然很高興看到它們被新增到語言中。

auxym：出於好奇，真誠的問題，因為我根本沒有接觸過Go。沒有泛型的容器型別（如陣列或雜湊圖）如何工作？您是否基本上必須為每種不同的包含型別宣告和實現型別/方法？

SiVal：我幾乎不需要直接使用泛型。如果我必須針對兩種型別編寫演算法，則可以像處理抽象型別程式設計所帶來的複雜性一樣輕鬆地進行復制和調整。
但是，我需要泛型。數十年來，我一直使用多種語言進行工作，並且我對具有成熟/已除錯/最佳化的演算法和資料型別標準庫（尤其是“容器”）的語言高度評價。
Go有一個貧乏的“內建”子集，僅此而已。
關於Go的最好的事情之一就是其標準庫的高質量，它具有標準庫。因此容器和演算法庫應該存在一個空白。這些演算法的專家可以利用Go的併發性來編寫庫演算法，這些庫演算法提供了效能和安全性的結合，而我根本無法快速建立。
當人們（反覆地）聲稱Go並不需要真正的泛型，因為他們幾乎不需要泛型，我不得不懷疑他們對DS和演算法的瞭解是特別高還是特別低：或者他們是否甚至不知道他們本來應該使用的DS /演算法。

catlifeonmars：就個人而言，我很少需要專門的演算法。我不確定這是否主要是我從事的問題空間（提供使用者身份和訪問管理的服務），但我從來沒有發現需要超越蠻力搜尋或需要除陣列或內建雜湊以外的資料結構對映（有時是併發雜湊對映）。我所做的大多數最佳化都涉及消除網路呼叫和實現快取。

zeugmasyllepsis：Go支援一些內建的泛型型別，例如雜湊圖。Go目前缺少的是使用者定義的泛型，儘管正在積極研究中。
 

Go vs. Python

zozbot234 ：是的，Go當然比Python更容易閱讀。這主要是因為Go是靜態型別的，並且具有良好的IMO編輯器工具。在設計中不要原諒其他暴行。

skj：對於大型python專案，由於繼承和混合，通常很難弄清楚下一步將執行什麼程式碼。
使用Go，通常非常簡單，是的，有介面，但是它們用於人們實際上希望程式碼選擇是動態的地方，而不是人們只是以DRY的名義開心地建立瘋狂的層次結構。
因此，有了Go，我發現它非常易於閱讀，因為它具有較高的程式碼區域性性，並且易於透過函式呼叫跟蹤到正確的目標。
對於已經本地化的事物，“易於閱讀”只是“熟悉”的程式碼。Go絕對更容易閱讀，因為透過跟蹤進行絕對更簡單。其他任何事情都只是在拼寫，只有很少的經驗，這些障礙就消失了。

joshuamorton：例如，對於某些特定型別的python而言這是正確的，但對於我編寫的大多數python程式碼而言，則並非如此。我會向您洗腦“鼓勵不復雜的體系結構”是一件好事，但是Go在另一個方向上搖擺得太遠了，例如python中的set（foo）-set（bar）表現得非常好（並且高效）的方法來給我foo中沒有的東西。
在執行過程中，您可以將其作為巢狀的for迴圈（難於讀取，而不是n ^ 2而不是n）來進行，也可以顯式迴圈遍歷每個迭代器並轉換為對映（公平地講，這正是python所做的也可以），然後自己編寫map差異圖，這很容易搞砸，應該進行徹底的測試以確保您在實現中沒有犯任何錯誤。
在python中，它的一行清晰，有表現力的，已知正確的程式碼。當然，泛型提議是想在功能上的改善做很多工作，但是我不同意go的“嚴格意義上是容易做的”，因為通常會有更多的可追溯之處，因為該語言為您提供的抽象要少得多，因此與其要展開使用某些高階語言功能的單個複雜表示式，您必須展開本地專案中這些抽象的pseduo重新實現。

LandR ：go太冗長而難以閱讀。我認為它是目前表達能力最差的語言之一。

sangnoir：缺乏表達能力會提高可讀性：在團隊環境中，並非每個人都以易於理解的方式“表達”自己。程式碼只寫一次，但是卻讀很多遍。
我曾經在一個維護大型Perl程式碼庫的團隊中工作：Perl既可以表現力又簡潔，但這會降低可讀性，尤其是在同事感覺喜歡使用晦澀的語言功能以“精妙的”單行程式碼表達他們的聰明/個性的時候。當聰明的程式碼有錯誤時，您將不得不以更加“聰明”的方式修復邊緣情況，或者將其展開為可讀的函式。

corty ：Go可以輕鬆替換Python或Ruby（因為它速度更快並且可以使用庫來滿足您的需要）。Go可以代替Java和C＃，因為併發更容易並且效能相當。Go不能在任何功能中替換C ++，因為C的編譯器太低階了，底層的東西是不可能的，並且Go庫將永遠無法與C和C ++相提並論。
但是總的來說，Go很不錯，因為有足夠的工具可以很好地完成大多數事情，並且該語言足夠原始，可以使該工具在幾乎所有情況下都能正常工作。這與C ++不同，因為那裡的工具對於模板，宏，繼承和指標總是太愚蠢。
而且它不同於Java，後者的工具過於複雜，緩慢且價格昂貴。
另外，Go還沒有積累太多的“驚奇”錯誤特徵，因此與父代命名的任何其他語言相比，可以更可靠地編寫和檢查程式碼。恐慌可以看作是這種功能失常的罕見情況，但通常僅用於表示通常無法恢復的問題，例如“記憶體不足”。因此，異常遠非the腳。

cle：幾年來，我維護了數十萬行Go程式碼。我不會為此選擇其他語言。
維護這樣的程式碼庫的重要屬性是語言規律性（大多數程式碼以相同的方式編寫，並且您不必對事物進行個人的“品味”決定），良好的文件和線上社群，維護良好的庫，工具功能用於版本控制和名稱空間，簡化部署等。
我同意Python非常適合面試。除非有真正令人信服的理由，否則我不會將Python用於由一群人維護多年的大型程式碼庫。

kuang_eleven：
Python具有所有這些功能：

• -語言規範；黑色是多年來的預設設定，如果您想強制使用其他樣式，則可以使用其他工具
• -文件和線上社群；甚至沒有競賽，在廣泛的文件和線上支援中沒有語言能與Python相提並論
• -庫；幾乎一樣，Python標準庫是世界一流的
• -版本控制和名稱空間；根據您的需要，Python再次變得更強大，Go中的名稱空間是一場災難。
• -部署簡單；...好吧，你得到了這個。Python部署比預期的難。不過，我發現我的Docker映像在兩者之間具有相同的複雜性。使用Python進行更復雜的部署，但無需編譯

其他

baby：Golang的全部重點是易於閱讀，有助於和維護。這是因為它的表現力較差，並且在編寫程式碼時具有較少的自由度。反過來，這會使編寫程式碼更加困難，但是如果您想使閱讀程式碼更容易，那就是必須要權衡的問題。
我堅信，人們已經能夠在沒有泛型的情況下編寫出驚人的大型應用程式，而泛型的新增只會扼殺Golang的最大功能之一：簡單性。