最近在 Go 程式語言社群圍繞 Hyrum 定律的討論，引發了關於 API 設計、向後相容性以及軟體開發實踐中意外後果的深入探討。雖然最初的文章主要關注一個無法更改的簡單錯誤資訊，但社群的反響揭示了軟體開發挑戰中更深層次和複雜的問題。
Go 語言錯誤處理的演進
Go 社群的討論突顯了該語言在錯誤處理方面的演進歷程。早期的 Go 缺乏像 errors.As 這樣的複雜錯誤處理機制，導致開發者不得不依賴字串比較來進行錯誤檢查。這種歷史背景造成了語言維護者現在必須謹慎管理的技術債務，他們需要在改進需求和對向後相容性的堅定承諾之間取得平衡。
隨機化策略
討論中出現了一個防止意外依賴的有趣方法。Go 的標準庫deliberately在某些操作中引入隨機性，以防止開發者依賴實現細節。例如，map 迭代使用隨機順序，加密函式也有意包含隨機位元組讀取。這種策略代表了一種主動預防意外依賴形成的方法。
Go 語言主要的向後相容性措施：
- 隨機化的對映迭代順序
- 在加密函式中有意進行隨機位元組讀取
- GODEBUG 功能標誌機制
- 保留特定的錯誤資訊字串
- 為遺留行為提供相容性墊片
Windows 遺留問題
討論中提到了 Hyrum 定律的一個經典案例：Windows 95 與 SimCity 的相容性問題。當 Microsoft 發現 SimCity 依賴於 Windows 3.x 中的一個記憶體管理特性時，他們專門為該遊戲實現了一個特定的相容模式。這個歷史案例表明，即使是主要的軟體平臺有時也必須保留bug以維持相容性。
現代 API 設計方法
Go 團隊目前管理 API 演進的策略包括使用特性標誌和 GODEBUG 機制。這種方法在需要行為改變時允許更可控的過渡，同時仍然保持語言強大的向後相容性保證。
在 Go 中，我們非常重視 Hyrum 定律（和向後相容性）。我們經常討論在文件中做出什麼承諾，以及哪些行為需要宣告可能改變，因為我們知道我們永遠不能改變已記錄的內容，而且可能也不能改變未明確記錄的內容。
展望未來
社群的討論表明，人們越來越意識到需要在 API 設計中採用更好的實踐。雖然 Go 對向後相容性的承諾一直是其成功的基石，但越來越多的共識認為，未來的語言版本和 API 設計應該包含防止意外依賴形成的機制。
Go 語言中關於 Hyrum 定律的討論為更廣泛的軟體開發社群提供了寶貴的經驗，強調了謹慎的 API 設計的重要性以及看似微小的實現細節可能帶來的長期影響。