← 返回 Siami 首頁

Google 工程團隊主張:Go 是 AI 輔助程式設計的理想語言

▲ 305 💬 357
Google 工程團隊主張:Go 是 AI 輔助程式設計的理想語言

編按:本文綜合整理自 Google Developers Blog〈Why Go is an ideal language for AI-assisted software engineering〉,並加入 Siami 編輯部觀點與分析。

Google 工程團隊 8 月發表了一篇引發熱議的文章,主張在 AI 輔助程式設計的新時代,Go 語言比其他主流語言更適合——核心論點是當 AI 幫人類寫程式,瓶頸不再是「寫」的速度,而是「讀、審查、維護」的速度。這篇文章在 Hacker News 上獲得超過 350 個留言支持,卻也引來大量反彈。


從「寫得快」到「看得懂」

過去三十年,開發者評估程式語言的標準是「寫起來多快」。但 AI 寫程式 agent 已經能在幾秒內產出數百行語法正確的程式碼,瓶頸完全翻轉:

  • 程式碼產生速度不再是稀有資源
  • 審查、驗證、維護才是真正的人力成本
  • AI agent 是隊友,但需要明確的規則協作

這正是 Go 語言 20 年前由 Rob Pike、Robert Griesemer 和 Ken Thompson 在 Google 創立的初衷——「為軟體工程而設計的語言」,而不是「為寫程式而設計的語言」。


Go 的三大主張

文章從三個面向論證 Go 對 AI 寫程式特別友善:

1. 平台一致性高於語言本身

Go 不只是語言,更是完整平台。從第一天起,內建格式化工具(gofmt)、測試框架、相依管理、安全掃描工具(govulncheck)。當整個社群都用同一套工具,AI 模型的訓練資料更一致,產出的程式碼也更標準。

2. 可讀性優先於寫法簡潔

Go 強制統一格式,刻意限制複雜抽象。團隊裡高級工程師、Junior、甚至 LLM 寫出來的程式碼「看起來都一樣」。這種結構統一對 LLM 特別有利——如果一個語言提供十種方式表達同一件事,AI 必然寫出支離破碎的風格混亂。

3. 靜態型別把關編譯速度

Go 編譯器能在毫秒級拒絕「呼叫不存在的方法」「傳錯型別」「變數未初始化」這類錯誤。AI agent 在自修正迴圈裡可以極高速迭代,比 Java / C# / Rust 快幾個量級。LLM 對 Python 這類動態語言容易產出「執行期才崩」的 bug,Go 在編譯期就擋掉。


🚨 為什麼這件事重要

這篇文章不只是 Go 語言的行銷。背後有一個更深的訊號:AI agent 的工作場景,正在重新定義「好語言」的標準。

過去十年的語言排行榜(RedMonk、Stack Overflow Survey)一直把 Python、JavaScript、Java 放在前三——這些語言的共通點是「容易寫、容易上手」。但在 LLM 接手寫程式後,這個優勢變得無關緊要。真正的贏家會是:

讓 AI agent 難以犯錯、讓人類快速驗證、十年後仍可維護的語言。

這個標準對 Rust、Go、Nim、Elixir 等「強約束語言」有利;對 Python、Ruby、JavaScript 等「快速原型語言」構成結構性壓力。

市場訊號:Google 在內部大規模推 Go、Tailscale、Cloudflare、Uber、Netflix 等基礎設施公司都是 Go 大戶,這不是偶然——這些公司正是最早面對「AI agent 接管 DevOps 自動化」需求的組織。


🚨 數據解讀與質疑

雖然這篇文章論述完整,但 HN 上的反對聲音值得認真對待:

1. 並發與正確性爭議

多位資深開發者指出 Go 的並發原語(goroutine + channel)對人類是直覺,對 AI 反而是陷阱——LLM 寫的並發 Go 程式容易產生 race condition、nil pointer、共享狀態污染。Go 編譯器擋得了型別錯誤,擋不了邏輯錯誤。

2. 表達力不足

Go 刻意限制泛型、不支援繼承、錯誤處理只能 if err != nil。對 AI agent 來說,這意味著模型難以表達複雜領域邏輯,反覆寫出冗長、重複的 boilerplate。

3. 創作者偏見

批評者 Havoc 直接點出:「這篇文章如果由 Go 語言創作者以外的人寫會更有說服力。」Google 對 Go 有巨大商業利益,不應忽視這層 bias。

4. 真實世界的衡量缺口

目前沒有公開的、可重現的 benchmark 能證明「LLM 寫 Go 的 bug 率顯著低於 Python/Rust」。HN 用戶 threethirtytwo 的評論最中肯:「在可以量化『slop 程度』之前,這都只是猜測。」


延伸閱讀


Siami 觀點:AI 寫程式時代,語言選擇變成「驗證成本」的選擇。Go 的強約束適合「高信任、高頻交易、AI 監控嚴密」的後端系統;Python 的彈性適合「快速原型、資料科學、AI 開發框架」;Rust 的 borrow checker 適合「效能關鍵、安全零容忍」。沒有銀彈,只有適配。

網友熱門留言 (10)

#1 beaker52 ▲ 89
就算 LLM 再會寫 Go,編譯器擋不住它在程式的另一個部分留下無效狀態——這是 race condition。對我來說這點最重要。
#2 jeanbza (Netflix Go 語言負責人) ▲ 78
完全同意這篇文章。在 Netflix 帶領 Go 語言社群,最近越來越多回報指出,AI agent 寫的 Go 比其他語言還好。我們的工具組建構在最一致的基礎上,這對 AI 寫程式來說是關鍵。
#3 zarzavat ▲ 72
現在選擇很簡單:效能要快用 Rust;迭代要快用 TypeScript;腳本或數值運算用 Python。LLM 對語言差別已經不太敏感。Go 本身不再是首選,它解決的是團隊問題,不是 AI 問題。
#4 CoolestBeans ▲ 65
Google 這篇文章的手法真漂亮——反正現在 AI 在寫程式,Go 寫起來不有趣也沒關係。但過去三十年對人類寫 Go 沒幫助的設計,突然對 AI 變得很有用?這說法實在很難說服人。
#5 Havoc ▲ 64
這篇文章如果由 Go 語言創作者以外的人寫會更有說服力。我個人偏向用 Rust 給 LLM:那些嚴格的編譯器跟錯誤訊息正是 LLM 需要的——快速、無歧義的回饋讓模型可以自我修正。
#6 cztomsik ▲ 58
留個預測幾年後回來看:JS 是記憶體安全、單執行緒、訓練資料海量,是我的首選。Python 第二。Go 第三(編譯太慢、套件生態太分散)。Rust 不會進入主流。
#7 CopyOnWrite ▲ 55
不同意。LLM 連最簡單的並行程式都會寫出 bug。Go 無法建立像樣的抽象,套件管理又像西部荒野,每個團隊都發明自己的框架。
#8 blindseer ▲ 52
很難不覺得 Google 是在汙染未來 LLM 的訓練資料,好讓模型傾向選 Go。Rust 或 Nim 才是真正適合 LLM 的目標——嚴格的編譯器、明確的語意、零隱式行為。
#9 dgunay ▲ 50
我喜歡 Go,但這篇文章列的優勢在 AI 規模下很多會被沖淡。可讀性沒錯,但 Go 缺乏進階型別系統讓 LLM 難以表達複雜領域邏輯;併發原語太簡單反而讓 AI 寫不出正確的並行程式。
#10 jpgvm ▲ 48
事實上並非如此。Go 的正確性保證很差,特別在並發上。Nil pointer。LLM 像放大鏡:你輸入什麼,它就放大 10 倍輸出。Go 缺乏類別繼承、泛型不完整、錯誤處理還在用 if err != nil——這些都會被 AI 放大。