📅 กรกฎาคม 2026
⚠️ อ้างอิงจากแหล่งปฐมภูมิ ตรวจสอบแล้ว — 但請先確認最新資訊再分享

如果 Pike、Thompson 和 Griesemer 是創造 Go 的人

Russ Cox 就是讓 Go 從 Google 內部的語言，成長為全球開發者共同使用的 ecosystem。他撰寫 gofmt、設計 Go modules、提出 Minimal Version Selection 演算法、撰寫 compatibility promise，目前擔任 Go tech lead——決定 Go 未來發展方向的人。

每次你輸入 go build 且程式在幾秒內完成編譯，那就是 Cox 的功勞。

來自 MIT 的 Plan 9 少年

當同齡人都在使用 Windows 或 Mac 時，Russ Cox 卻選擇使用 Plan 9——由 Rob Pike、Ken Thompson 和 Dennis Ritchie 在 Bell Labs 開發的作業系統。

他每天都以 Plan 9 作為主要作業系統。

在 MIT 求學期間，Cox 直接與 Pike 合作參與 Plan 9 專案，並共同撰寫論文「Security in Plan 9」（USENIX 2002），當時他還只是學生。

然而當網路變得越來越重要時，Plan 9 卻缺乏可用的網頁瀏覽器。

Cox 沒有轉而使用其他作業系統，而是做了優秀程式設計師會做的事：將整個 Plan 9 移植到 Unix。

plan9port 是在 Linux 和 macOS 上運行的 Plan 9 使用者空間，你可以在一般電腦上使用 acme 編輯器、sam 編輯器、rc shell、plumber 等 Plan 9 的所有工具。

Cox 至今仍每天使用 Acme 作為主要編輯器。

這正是 Pike 注意到他的原因：「這個孩子對 Plan 9 的理解，足以將整個系統移植過來。」

Google Code Search 與 RE2

Cox 在 MIT 攻讀博士學位期間，曾到 Google 實習。

讓他聲名大噪的作品是 RE2——他為 Google Code Search 撰寫的正規表示式引擎。

一般正規表示式引擎的問題在於 catastrophic backtracking：某些 pattern 可能花費數分鐘、數小時，甚至導致程式崩潰，因為 backtracking 演算法在最壞情況下呈指數級增長。

Cox 運用他在研究中學到的自動機理論，設計出能保證 線性時間 的 RE2，無論 pattern 有多複雜。

從 2006 年起，RE2 就在 Google 的生產環境中使用——包括 Google Code Search、Google Sheets，後來更成為 Go 標準函式庫中的 regexp 套件。

他撰寫的三篇系列文章，已成為正規表示式領域的經典參考：「Regular Expression Matching Can Be Simple And Fast」、「Regular Expression Matching: the Virtual Machine Approach」、「Regular Expression Matching in the Wild」。

2008 年 — Pike 邀請他加入 Go 團隊

Cox 即將在 MIT 完成博士學位（論文題目為「An Extension-Oriented Compiler」）時，Pike 來邀請他。

Pike 說道：「我們想把在 Plan 9 上開發軟體時所熱愛的一切，應用到 Google 想撰寫的軟體上，你願意加入嗎？」

Cox 回答：「Yeah, of course」

他成為 Go 團隊的第四位成員，繼 Pike、Thompson、Griesemer 之後加入。

gofmt — 第一個專案

Cox 在 Go 團隊的第一個工作就是 gofmt。

2009 年 12 月，他發表部落格文章宣布 gofmt——這款工具能自動將 Go 程式碼格式化成統一風格。

聽起來像是小事，但 gofmt 是 Go 歷史上最聰明的決定之一。

在 gofmt 出現之前，Go 團隊曾花費大量時間爭論程式碼風格：大括號應該與 if 放在同一行還是新的一行？縮排應該用 tab 還是空格？逗號後面要不要加空格？

有了 gofmt 之後，這些問題永遠消失了。

如今全球所有的 Go 專案看起來都一模一樣，無論你閱讀的是 Google、初創公司，還是開源貢獻者的程式碼。

go 指令 — 你每天都在使用卻從未思考過它

Cox 設計了 go 指令——go build、go test、go get——這些你每天都會輸入的指令。

但真正讓 Go 徹底改變的作品是 Go modules。

Go Modules — Go ecosystem 的轉捩點

在 Go 1.11 之前，Go 的依賴管理是一場災難。

go get 直接從版本控制系統抓取程式碼，沒有版本控制、沒有 lock file。一個專案的依賴可能在不知不覺中升級，進而破壞另一個專案。

2018 年 2 月，Cox 推出 vgo——他獨自撰寫的 Go modules 原型。

接著他做了幾乎沒有人做過的事：撰寫 10 篇系列部落格文章，解釋每一項決策。

  • 為什麼需要 semantic import versioning
  • Minimal Version Selection 是什麼，為什麼比 npm 的 SAT solving 更好
  • reproducible builds 如何運作
  • Go 的版本控制原則

Minimal Version Selection (MVS) 是 Cox 自行設計的演算法。它不會像 npm 那樣試圖找出「最佳的依賴版本組合」（使用 SAT solver 且耗時甚久），而是選擇滿足所有模組需求的最低版本。

結果：go mod tidy 能在 2 秒內完成，而不是花費數分鐘解析依賴樹。

Go modules 在 Go 1.13 成為標準，並在 Go 1.16 成為預設功能。

Go Compatibility Promise — 10 年前的程式碼仍可編譯

2023 年 8 月，Cox 撰寫部落格文章「Backward Compatibility, Go 1.21, and Go 2」。

文章開頭的那句話，已成為 Go 的座右銘：

"Boring is good. Boring is stable. Boring means being able to focus on your work, not on what's different about Go."

Cox 負責維護 Go 的 compatibility promise，審查每一項可能破壞向後相容性的變更。

試想其他語言：2012 年的程式碼無法在 2026 年的編譯器中編譯，除非進行修改。

Go 做到了，因為 Cox 和團隊將相容性視為最高原則。

透明的決策過程

Cox 改變 Go 團隊工作方式的，不僅是程式碼，更是流程。

他設計了 Go proposal process——每一項重大變更都必須經過 GitHub 上的公開 proposal，並附上設計文件說明問題、替代方案和理由。

他撰寫了 6 篇系列部落格文章說明這個流程：「Clarity & Transparency」、「Large Changes」、「Scaling Discussions」、「Enabling Experiments」、「Representation」。

沒有「房間裡最聰明的人做決定」。從 Go 1.0 到現在，Go 的每一項決策都有文字記錄。

這就是 Cox 所謂的「language design in the service of software engineering」——語言設計不是天才的藝術，而是有流程、有理由、有記錄的工程。

哲學

Cox 的 GitHub 簡介寫道："Go Hacker. Mistake maker."

他從不假裝自己什麼都知道，而這正是最令人尊敬的地方。

2018 年在 GoTime 的訪談中，他談到最初的期望：

"My hope was that maybe a few people would notice, and ideally whatever the next big language to come along would steal the concurrency and the interface ideas from Go, and that would be our tiny little contribution to making programming a little bit better. Obviously, that didn't happen, but I'm okay with how it turned out instead."

「希望有幾個人會注意到」——結果 Go 成為全球生產環境中廣泛使用的語言。

Cox 的另一面——數學家

Cox 不只是 Go 工程師。

他是 OEIS Foundation 的主席（Online Encyclopedia of Integer Sequences）——世界上最大的整數序列資料庫。自 1964 年以來，數學家和電腦科學家一直將 OEIS 作為參考。

他在 2024-2026 年發表的部落格文章，大多與浮點數格式化有關——深入探討「Pull a New Proof from Knuth's Fixed-Point Printer」和「Fast Unrounded Scaling: Proof by Ivy」等主題。

他使用 Rob Pike 撰寫的 APL 風格計算器語言 Ivy，證明數學演算法的正確性。

這就是同一個人：一天設計 Go modules，另一天用形式證明驗證浮點數格式化器是否正確運作。

其他作品

在加入 Go 之前，Cox 已有許多作品：

  • Vx32 沙箱系統（USENIX 2008）
  • Vivaldi 網路座標系統（SIGCOMM 2004）——用於在分散式系統中找出節點間的延遲，而無需測量每一對節點
  • Xoc 可擴展編譯器（ASPLOS 2008）

加入 Go 之後：

  • Go Memory Model——撰寫文章解釋 Go 的記憶體模型和硬體記憶體模型（2021-2022）
  • Transparent Telemetry——Go 工具鏈的使用資料透明收集系統（2022）
  • Coroutines for Go——Go 的協程提案（2023 年 7 月）
  • xz backdoor analysis——分析 xz 函式庫後門的時間軸（2024）

如今

Cox 仍是 Go tech lead，在 Google Cambridge, MA 工作，每天使用 Acme 編輯器。

他定期在 research.swtch.com 撰寫部落格，已發表 150 多篇文章，且持續增加中。

2024-2026 年：撰寫 Go Changes、Go Testing By Example、浮點數格式化系列、基於雜湊的二分除錯、差分覆蓋率等文章。

他不是擁有數萬觀眾的 keynote 演講者，但每次他撰寫文章，Go 團隊和社群成員都會閱讀。

Cox 與台灣程式設計師

能在 2 秒內完成的 go mod tidy，是 Cox 的功勞。

讓所有 Go 專案程式碼風格一致的 gofmt，是 Cox 的功勞。

讓 2012 年的 Go 程式碼在 2026 年仍可編譯的 compatibility promise，是 Cox 的功勞。

以及成為 Go 社群 DNA 的「透明決策、撰寫可供閱讀的理由」文化，

都是 Cox 所建立的。

總結

Rob Pike、Ken Thompson、Robert Griesemer 是創造 Go 的人。

但 Russ Cox 是讓它得以存續的人。

來源：swtch.com/~rsc、research.swtch.com、go.dev/blog、GoTime #77、github.com/rsc、github.com/google/re2、pdos.csail.mit.edu/~rsc