Go 寫 LSP 少寫一堆樣板

說真的，這題很實際。glsp 這個 Go 函式庫，直接把 LSP 3.17、handler 自動註冊，還有 debug server 一次包進來。對開發者來說，少寫一堆樣板碼，通常比多一個花俏功能更有感。

你可能會想問，為什麼要在意 LSP。因為一套語法提示、診斷、跳轉定義，可以同時送到 Visual Studio Code、JetBrains IDEs，還有其他編輯器。不是每個工具都值得做一個完整外掛，但很多工具都值得有編輯器支援。

這篇我想講白一點。這不是在吹 protocol 很偉大。重點是，Go 開發者現在多了一條更省事的路，可以把 CLI、Makefile、GoReleaser 這類工具，直接接進編輯器工作流。

glsp 到底在解什麼痛點

glsp 的定位很直白。它想讓你用 Go 寫 language server，還不用手動處理太多 protocol 接線。對很多人來說，LSP 最大的痛不是協定本身，而是周邊雜事太多。

像是初始化流程、method dispatch、request response、error handling，這些東西一堆。你本來只是想做 completion，結果先寫了半天框架。說真的，這種體驗很勸退。

glsp 的做法是用 interface 來自動註冊 handler。你定義 hover、diagnostics、completion 這些功能時，不用自己手動把每個 method 接到 router。這種設計很 Go，也很對味。

• 支援 LSP 3.17
• handler 可以自動註冊
• 內建 debug server
• 已有 Makefile 範例
• 也有 GoReleaser 範例

這些例子很有意思。因為它們不是教科書案例，而是日常會碰到的檔案。Makefile、CI 設定、發版腳本，這些東西常常沒人想寫完整 IDE 外掛，但又很需要提示和檢查。

我覺得這就是 glsp 的價值。它不是要你重做一個 IDE。它是讓你把既有工具，補上編輯器那一層。

為什麼自動註冊這件事很重要

很多 framework 都會說自己很簡潔。真正用下去才知道，簡潔常常只是把複雜藏起來。glsp 比較討喜的地方，是它把 wiring 縮到很小，而且還保留 Go 的明確感。

在 Hacker News 的討論裡，有人直接稱讚這種 interface-based auto-registration pattern。這不是空話。因為在 LSP 這種場景，手動接線越多，越容易漏 method，或是加功能時改到一半忘記掛上去。

作者也提到一個很現實的行為差異。handler 回傳一般 error 時，server 會送 error response，然後繼續跑。可是如果 handler panic，server 會直接掛掉。這種細節很重要，因為它決定了你敢不敢把它放進真實專案。

“That’s the kind of API design that makes Go’s implicit interfaces shine.”

這句來自 HN 討論。講得很準。Go 的 implicit interface 本來就適合做這種事。你不用先註冊一長串表格，只要把方法做對，框架就能抓到。

另外，debug server 也很實用。LSP 的 bug 常常不是語法錯，而是訊息在 editor、server、parser 之間轉錯。能直接看訊息流，排錯時間會少很多。這不是炫技，是救命。

跟其他 LSP 工具比，差在哪

Go 世界裡不是只有 glsp。作者自己也提到，他一開始是從 tliron/glsp 起步。後來自己做一套，主要是想要 debug UI 和更順手的開發體驗。

這點很像很多工程團隊的真實選擇。不是原本工具不好，而是它不合你的工作流。你如果每天都在看 message flow，沒有 debug 視圖真的很痛。

如果把幾個方案放在一起看，差異就比較清楚。LSP 本身是標準，但實作體驗差很多。下面這幾點，會直接影響你會不會真的把它用進產品。

• tliron/glsp 是既有選項
• owenrumney/glsp 主打 debug-first 工作流
• VS Code LSP 指南 顯示 protocol 重用的好處
• LSP 能讓不同編輯器共用同一套邏輯
• warg 也被討論到可加上 LSP

如果你做的是 CLI 或內部工具，這個比較就更有意思。你不一定需要完整 GUI，但你很可能需要 hover、completion、diagnostics。這些功能一旦做進去，使用者會覺得你的工具比較像「活的」。

我自己的判斷很直接。glsp 這類工具的競爭點，不是誰支援更多行為，而是誰讓你更快做出能上線的 server。對團隊來說，少一週樣板碼，通常比多十個抽象更有價值。

數據和競品角度怎麼看

如果只看 HN 討論熱度，這篇有 92 points。這數字不算炸裂，但足夠說明一件事：開發者對「少寫 LSP 樣板」是有感的。尤其是做 Go 的人，對這種簡潔 API 特別挑剔。

再看使用場景。Makefile、GoReleaser、YAML、Terraform、內部 DSL，這些東西都很適合 LSP。因為它們常常有固定結構，卻又很難靠純文字編輯保證正確。編輯器幫你檢查，會比事後 CI 才報錯舒服很多。

下面這種比較方式比較務實。不是看誰名氣大，而是看誰比較適合落地。很多工具最後卡住，不是功能不夠，而是整合成本太高。

• 手動寫 editor plugin：每個編輯器都要重做一次
• 用 LSP：一套 server，多個 editor 共用
• 用 glsp：少掉不少 handler wiring
• 用傳統 framework：可能更成熟，但 debug 體驗不一定順
• 對 CLI 工具來說：補 LSP 往往比加更多 flag 更有感

這裡還有一個很現實的比較。VS Code、JetBrains、Neovim、Emacs 都能吃 LSP。你如果自己寫插件，維護成本會很高。你如果把重點放在 server，整體成本通常低很多。

所以 glsp 的意義，不只是「又多一個 Go library」。它是把 LSP 的進場門檻再往下壓一點。對想把工具做成編輯器友善的團隊，這很有吸引力。

Go 為什麼很適合做這類工具

Go 做工具鏈，本來就很順。編譯快、部署單檔、標準函式庫夠用。對 language server 這種長駐服務來說，這些特性都很實際，不是口號。

更重要的是，Go 的 interface 很適合拿來做 handler discovery。你不用搞太多魔法，也不用把整個系統做得很黑盒。對維護者來說，這很重要，因為 LSP 已經夠複雜了。

從產業角度看，這種工具會越來越常見。原因很簡單。很多團隊不是沒有工具，而是工具只活在 CLI。只要把 editor support 補上去，使用者感受就差很多。

這也是為什麼像 Makefile LSP 這種東西會有存在感。它不是做一個新語言，而是把老工具變得比較好用。老實說，這種改造常常比新框架更有價值。

我會怎麼看這波。若 glsp 持續把 panic handling、debug 視圖和文件補齊，它很可能會吸引更多 Go-heavy 團隊試用。尤其是那些已經有 parser、validator、CLI 的專案，接 LSP 的成本會比重寫一個 editor plugin 低很多。

接下來最值得看的事

我覺得接下來最值得觀察的，不是 glsp 會不會變成最大宗方案，而是有多少工具會開始把 LSP 當成標配。當 CLI、設定檔、內部 DSL 都能快速接上 editor 支援，開發者體驗會更完整。

如果你現在在做 Go 工具，我會直接問一句：你是想再加一個 flag，還是想讓使用者直接在編輯器裡看到診斷和 completion。很多情況下，答案其實很明顯。

講白了，這類 library 的價值在於省時間。不是省一點，是省掉一整段重工。對團隊來說，這種省法通常比任何漂亮 demo 都更有說服力。

如果你手上有 CLI、Makefile 工具，或任何結構化文字格式，我會建議你真的試一次 LSP。先把最常見的 2 到 3 個功能做出來。像 hover、diagnostics、jump to definition，就很夠用了。