Rune IDE 開源釋出

Rune 現已開源

Unstable Build 已將 Rune 開源，這是一款從零開始以 Go 語言打造的原生圖形化 IDE，採用 GPLv3 授權。此專案旨在彌補高迭代速度的管理語言與高效率的系統語言之間的差距，同時引入一種創新的貢獻者計畫，將公司收益與參與開發者共享。

原生、字元格線的 IDE 架構

Rune 設計為一個以字元格線為核心的原生圖形應用程式，而非終端模擬器或 Electron 應用。此架構選擇使 UI 可以獲得 GPU 加速，同時保持類似終端的簡潔介面，並避免瀏覽器執行環境帶來的效能開銷。

Go 中的效能工程

雖然初期速度不如以 Rust、Zig 或 C 寫成的終端，Rune 的終端已優化至可與 Alacritty、Ghostty 和 Kitty 等業界領先者競爭。開發團隊在不使用 cgo 進行手動記憶體管理的情況下達成此目標，方法包括：

更佳的演算法，以及更有效率地在 goroutine 之間分配工作。
平衡的 goroutine 唤醒，以最小化 Go 執行時的開銷。
事件驅動的渲染，擺脫每秒幀數（FPS）模型，以降低延遲。

在高階（Apple M4 Max）與低階（2016 MacBook）硬體上使用 vtebench 的基準測試顯示，Go 提供足夠的控制力，足以在這些特定工作負載下與系統語言達到效能對等。

核心設計原則

以終端為中心的 UI：終端是第一優先的元件，整體 UI 類似終端多路複用器。
統一的命令介面：模糊搜尋的命令提示列可處理編輯器操作、視窗管理與代理工作流程。
持久的 REPL：專用主控台用於套件安裝、模型設定與除錯器管理。
gRPC 擴充 API：編輯器核心保持輕量，透過 gRPC 暴露資源，讓擴充可使用任何語言撰寫。
P2P 網路：每個執行個體皆為安全 P2P 網路中的節點，支援使用者透過自訂的 rune:// 方案在不同機器上開啟工作區。

「反向 Rug Pull」貢獻者模式

為對抗企業開源專案後再重新授權以獲取價值的趨勢，Unstable Build 採用「反向 Rug Pull」模式。

收益共享與治理

GPLv3 授權：貢獻者保留其作品的著作權，Unstable Build 無法單方面將社群作品私有化。
財務激勵：參與貢獻者因被接受的工作獲得「貢獻積分」。符合資格的服務收入會被匯集，並根據其活躍積分比例分配給貢獻者。
可審計的帳本：所有關於收入、扣除與分配的計算皆維護於公開可審計的帳本中，確保透明度。
可選參與：開發者可透過標準的 GPLv3 與 DCO 流程貢獻，無需加入付款計畫。

語言支援與生態系

Rune 目前對 Go 和 Python 提供一等支援，Rust 與 Zig 支援目前在 main 分支上處於測試階段。Rune 中的「一等支援」不僅包含 Language Server Protocol (LSP) 整合，還包括專案發現、工具部署與生態系特定工作流程（例如直接在主控台整合 rustup）。

社群觀點與批判

公告後，開發社群對 IDE 的設計提出多項討論點：

入門門檻：部分使用者指出，Vim 模式入門流程過於嚴格，使新手難以在未完成特定訓練的情況下操作編輯器。
建置時間：部分貢獻者質疑 Go 建置時間快於 Rust 的說法，有使用者提供基準測試，顯示 Zed 在某些情境下建置時間可能更快。
字元格線的實用性：部分批評者質疑原生 GUI 模擬 TUI 的價值，認為可能結合終端的視覺限制與失去可移植性。
網路信任：使用者對 P2P 協調伺服器與加密方式的信任提出疑慮，建議可選性整合如 Tailscale 等工具。

"開源帳本與貢獻者利潤共享，可能比 IDE 本身更令人感興趣。"

"我喜歡文字提示命令的可發現性。我喜歡終端更像第一優先的元件。"

"Rune 是一個以字元格線為核心的原生圖形應用，而非在終端內執行的應用。所以它有 TUI 的視覺限制，卻沒有可移植性的優勢？為什麼要這樣做？"