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 中的 "一流支持" 不仅限于语言服务器协议（LSP）集成，还包括项目发现、工具部署和生态系统特定工作流（例如，将 rustup 直接集成到控制台中）。

社区观点与批评

宣布后，开发者社区对 IDE 的方法提出了若干讨论点：

• 入门摩擦：一些用户报告称，Vim 模式入门流程过于严格，使得新用户在未完成特定培训的情况下难以导航编辑器。
• 构建时间：一些贡献者质疑 Go 比 Rust 构建更快的说法，有用户提供了基准测试，表明在某些场景下 Zed 的构建时间可能更快。
• 字符网格的实用性：一些批评者质疑一个模仿 TUI 的原生 GUI 的价值，认为它可能同时具备终端的视觉限制和失去可移植性。
• 网络信任：用户对 P2P 协调服务器和加密方法所需的信任表示担忧，建议可选地与 Tailscale 等工具集成。

"对贡献者的开源账本和利润共享，可能比 IDE 本身更具创新性。"

"我喜欢文本提示命令的可发现性。我喜欢终端更像是第一优先级。"

"Rune 是一个围绕字符网格构建的原生图形应用，而不是运行在终端内的应用。所以它既有 TUI 的视觉限制，又没有可移植性的优势？为什么？"