2026年9月12日，我们将符文（Rune）以 GPLv3 协议开源，源码现已在 GitHub 提供，同时不稳定构建（Unstable Build）正创建新颖贡献者计划与参与者分享收益。此外，我们从第一性原理用 Go 语言打造新 IDE，现代 IDE 虽工程非凡但常基于庞大技术栈，难以理解编译或改动，除非熟悉系统语言或浏览器运行时代码库。

今天，我们以 GPLv3 开源 Rune。源码现在可在 GitHub 上获取。我们还在创建一项新的贡献者计划，把 Unstable Build 的收入分享给参与的贡献者。

一个用 Go 从第一性原理构建的新 IDE

现代 IDE 是了不起的工程作品。它们通常也建立在庞大的技术栈上，除非你熟悉大型系统语言或浏览器运行时代码库，否则很难理解、编译、分析性能或修改。这些都是合理的工程选择，但它们要么在“有想法”与“改变你每天大部分工作时间所处的环境”之间制造了很高的门槛，要么对现代 IDE 来说太慢。似乎没有方案能在迭代速度与性能之间取得恰当平衡。随着自动编程的出现，这比以往更重要。IDE 要么用 Rust 和 C/C++ 这类编写和编译都慢的语言，要么构建在难以适应性能关键负载的运行时上，比如基于 Electron 的 JavaScript 和 TypeScript 应用。

Rune 是一个围绕字符网格构建的原生图形应用，而不是运行在终端里的应用。

例如，Rune 的终端用 Go 编写，最初在伪终端（PTY）吞吐量上比分别用 Rust、Zig 和 C 编写的 Alacritty、Ghostty、Kitty 慢近两个数量级。

让它达到相近性能，并不需要通过 cgo 落入手动内存管理的语言。它需要结合更好的算法；更有效地把工作分配到 goroutines；平衡 goroutine 唤醒，避免 Go 运行时开销过大；最后，从用于渲染的游戏引擎继承的每秒帧数（FPS）驱动模型，改为事件驱动模型以降低延迟。

下面三张性能图用 Alacritty 的 vtebench 比较 Rune 终端与其他终端。测试在能拿到的最快笔记本——运行 macOS 的 Apple M4 Max、128 GB 内存——以及我们仍在开发使用的最慢笔记本——2016 年 Apple MacBook，在低功耗移动 Intel Core m3-6Y30 CPU 上运行 Linux——上进行。

第一张图包含 Alacritty、Ghostty、Kitty、Terminal.app、iTerm2、WezTerm 和 Rune，在 Apple M4 Max、128 GB 内存、macOS 上运行 vtebench。iTerm2 在若干滚动负载上比其他终端慢一到两个数量级，因此图表使用对数时间尺度，让每个终端都可见；越低越好。

第二张图去掉较慢终端，只在线性尺度上比较 Alacritty、Ghostty 和 Rune，便于一眼看出。图中是箱线图；箱体覆盖中间 50% 的运行，中线表示中位数，须线延伸到四分位距 1.5 倍内的最极端测量值，须线之外的测量值未显示。

第三张图在最慢硬件上重复同样比较：2016 年 Apple MacBook，低功耗移动 Intel Core m3-6Y30 CPU，Linux。图表同样是线性时间尺度的箱线图；越低越好。

这些不是语言基准测试，也不显示 Go 和 Rust 或 Zig 一样快。但它们显示了一件有用的事：通过性能分析和仔细工程，Go 给了我们足够控制力，把近两个数量级的差距缩小，并让 Rune 终端在这些负载上有竞争力，同时不放弃当初选择 Go 带来的简单性和迭代速度，还获得一门为构建分布式系统设计的语言，这对实现 Rune 网络之类的东西很有用。

为什么是现在？

我们很久以来就想开源 Rune。我们也想在合适阶段开源。

项目早期，小团队能以很难在公开场合复现的强度推进基础设计问题。IDE 的表面积巨大，几乎每个早期实现选择都可能意外变成 API、兼容性承诺或架构约束。

我们不想在仍在自我寻找时开源。Rune 还不完整，但重心已经清楚：

• 终端是环境的一等部分。Rune 是 IDE，但 UI 很像终端复用器。
• Rune 的控制台是我们开发 IDE 的地方：一个持久 REPL，用于安装包、配置模型、管理扩展和进程、驱动调试器。
• Rune 的命令提示符是我们驱动 IDE 的方式。编辑器操作、窗口管理、语言工具和代理工作流共享一个可模糊搜索的命令界面。命令可以输入，可以由扩展贡献，可以串成别名，也可以绑定到特定按键组合。
• GUI 是原生、快速、GPU 加速的，并围绕字符网格界面构建。我们知道这是巨大的取舍，但相信它让 Rune 能比其他 IDE 和编辑器走得更快。而且我们认为，为开发者实现一个可爱的 UI 并不需要超过一个字符网格。
• 编辑器核心保持小，并暴露资源给扩展，扩展通过明确的 gRPC API 通信。这让 Rune 可以用任何语言扩展，而不只是 Go 或当下流行的脚本语言。
• 每个 Rune 实例组成私有且安全的开发 P2P 网络中的一个节点。Rune 提供新的 rune:// 方案，用户可以在任何地方打开自己任意开发机器上的工作区，受 NAT 穿透约束。

这些决定给 Rune 一致的身份，也让贡献者有坚实的东西可构建。

反向抽地毯

过去几年，部分开源社区发生的事情令人震惊。公司在公开环境构建项目，从用户和贡献者获益，等项目有价值后改变许可证。宽泛的 CLA 会让这更容易，因为它们要求贡献者转让版权，或授予公司特殊的重新许可权利——其他参与者得不到这种权利。这在每个人都同意时可能合法，但不是我们想要 Rune 的方式。

Rune 将按 GPLv3 授权。贡献者保留自己作品的版权，并以与 Rune 其余部分相同的 GPLv3 条款贡献。Unstable Build 不会拥有特殊权利，把社区成果以后变成专有。

事实上，我们打算做相反的事。我们不会假设贡献者只对名声和声望感兴趣，要求他们向公司交出权利，而是给参与的贡献者一项合同权利，直接或间接分享 Rune 产生的收入。被接受的工作会获得贡献积分。符合资格的服务收入中，一个确定比例将注入贡献者池，每次分配按该期间活跃积分的比例划分。

计算会放在公开可审计的账本中：涵盖的收入、允许的扣除、贡献奖励、活跃积分、总分母，以及每次分配。贡献者可以复现计算，而不是相信关起门来产生的数字。参与是可选；任何人仍可按正常 GPLv3 和 DCO 流程贡献，而不加入付费计划。该计划不会让贡献者成为 Unstable Build 的员工、股权持有人或成员，也不会向公司转让额外软件权利。

我们仍在敲定法律细节，比如池比例、覆盖哪些服务、积分保持活跃多久、支付时间表。原则已经确定：公司不应在从贡献者获得特殊权利的同时，把所有经济好处留给自己。可从 Rune 账户页面注册该计划。

接下来

为你的语言带来一等支持

Rune 目前将 Go 和 Python 作为一等语言支持。Rust 和 Zig 支持处于 beta，可在 main 上从源码构建。我们正在寻找想主导自己语言和生态支持的开发者。

一等支持不只是连接语言服务器。它意味着项目发现、工具供应、语法和索引、调试，以及属于该生态的工作流。例如，Rune 通过 rust 命令暴露标准 LSP 方法之外的 rust-analyzer 操作，并通过控制台提供 rustup 来管理工具链，无需离开环境。

你可以从 Go SDK 和现有 Python 扩展开始，后者本身用 Go 编写。或者帮助把 SDK 带到你的语言，Python SDK 已开始这样做。我们希望开发者能用自己每天使用的语言扩展 Rune。

我们的开发者指南 Languages 通过构建 Python 集成，讲解架构、扩展生命周期、语法查询、索引、工具管理、打包和测试。

我们不想猜测优秀的 Elixir、OCaml、Clojure、Java、C# 或 TypeScript 环境应该是什么感觉。如果你使用这些工具，帮助我们设计它。从源码仓库开始，阅读贡献指南，探索开放 issue。

和我们一起构建 Rune

克隆源码仓库，阅读贡献指南，探索开放 issue，告诉我们你希望一个用 Go 构建的开发环境变成什么样。如果你对贡献者计划感兴趣，创建账户并从账户页面注册。

我们迫不及待想看看一起能做些什么。

社区对 Rune 这个用 Go 写的 GPLv3 IDE 总体好奇，愿意把它和 VSCode、Zed 比较并尝试；真正的分歧在于，把收入分给贡献者是修复开源被滥用，还是会用金钱污染贡献动机，以及网络协作是否必须信任官方服务器。技术质疑也没有缺席，构建时间和从零重写 IDE 的可行性都被点名。

认为利润分享和反 CLA 是比 IDE 本身更重要的创新

• 支持者把它看作对开源被滥用、资金匮乏的反制，GPLv3 也被视为加分项；作者强调参与者不必签 CLA 交出版权。（较多人） > 公开账本和利润分享给贡献者，可能比 IDE 本身更有意思。（@anigbrowl）

担心财务激励会招来刷量提交，而不是真正的上游修复

• 反对者认为贡献动机应只是修自己需要的缺陷或功能；Hacktoberfest、Tide 和人工智能生成的提交已经显示，直接给钱会引来为社交资本或收入而来的垃圾提交。（少数人） > 一旦给贡献直接财务激励，就会像 Hacktoberfest 和人工智能生成的提交那样，催生为社交资本而刷的量。（@_bent）

希望网络协作可选，不愿默认信任官方协调服务器

• 有人认可跨机器工作的便利，但担心协调服务器和加密方案；问能否走 Tailscale 或 SSH，另有人直接问能否离线运行。（较多人） > 我很想轻松跨机器工作，但不愿必须信任你们的协调服务器和加密方式，能可选地走 Tailscale 吗？（@rao-v）

愿意尝试，但 VSCode 和 Zed 仍是实际基准

• 多人表示会试用 Rune，有人等 Fedora 包，有人希望首页有使用视频、浅色主题，并询问键盘驱动是否意味着模态编辑；Zed 被频繁拿来对比。（较多人） > 不讨厌 Zed，只是对尝试新 IDE 上瘾。（@ramon156）

认为必须优先支持 TypeScript

• 有人指出 TypeScript 是最流行的语言，Cloudflare Workers 等场景也要求它；Go 编辑器不能只照顾 Go 用户。（少数人） > TypeScript 是最流行的语言，你们肯定得优先做 TypeScript 支持。（@robert-zaremba）

认为人工智能终端正在取代传统 IDE，编辑器未来黯淡

• 有人现在主要靠终端里的人工智能写代码，Emacs 只做少量查看；补全和语法高亮的重要性下降，非开发者用人工智能氛围编程可能连编辑器都不需要。（少数人） > 现在 Claude 在终端里越来越像我的 IDE；传统 IDE 前景不亮，90 年代的 vi 或 Emacs 可能就够了。（@pmontra）

认为从零写 IDE 会重复造轮子，语言支持难与现有工具链匹敌

• 质疑从头实现 C++、Java、Rust 等支持是否现实，因为其他 IDE 依赖大量外部库和编译器做重活；也追问博客中关于公司改许可证的指责具体指谁。（少数人） > 全部从零写会不会浪费巨大精力？真能复制其他 IDE 靠外部库和编译器完成的大量语言功能吗？（@einpoklum）

认为新手引导中的 Vim 模式摩擦过大

• 有 Vim 用户按引导开启 Vim 选项后完全无法操作，感觉像第一次用 Unix；建议大幅降低试用摩擦，或给自称 Vim 用户加警告。（少数人） > 我选了 Vim 模式后完全动不了，像第一次面对“怎么退出这个文本编辑器”的新手，只能立刻退出并卸载。（@threecheese）

有价值的补充

• 实测质疑构建时间：Rune 的缓存空构建约 22 秒，而 Zed 只改一个文件后的增量构建约 8.5 秒；问题包括 CGO 慢，以及空构建路径没有针对长构建对象优化。（@raggi）
• 有人关注终端性能基准 vtebench，并分享自建编辑器的经验：终端性能调优更多取决于内存访问和存储布局，而不是表面渲染。（@elcritch）
• 有人喜欢命令提示符的可发现性、终端的一等公民地位，以及能直接用 go run 启动，但认为当前主题较差，习惯 Solarized、Gruvbox 的亮暗主题。（@gregwebs）
• 作者补充说文章讲的是用 Go 构建 IDE 的部分细节，并介绍贡献者计划：把 Unstable Build 的部分收入分给参与者，而不是要求签 CLA 交出版权。（@ernestrc）