Shelley 为何用 Go 编写：exe.dev 谈智能体时代的语言选择

Shelley 主要用 Go 编写。

为什么选择 Go

当前围绕完全由智能体编写的代码的炒作周期集中在 TypeScript 和 Rust 上。这本身没什么问题。TypeScript 与 JavaScript 一样，是浏览器内软件仅有的两个正确选择之一，并且在服务端也有稳固的地位。Rust 是一门优秀的系统编程语言。用这两种语言你都能写出大量出色的软件。

但正如炒作周期一贯的作风，它们往往会抓住某个明显正确的事实，比如“TypeScript 和 Rust 可行”，然后加以外推。其中一个外推就是：Go 不可行，或者至少在代码由智能体编写的世界里不再有意义。

对我们来说，这并不是一个显而易见的结论。虽然关于编程语言的争论向来痛苦地停留在定性层面和审美层面，但 Go 在程序员中的流行程度在宏观上表明，它作为一门编写软件的语言是有价值的。它对开发者很友好。

exe.dev 的一条工作原则是：“对开发者有利的，就对智能体有利。”这就是为什么我们花了大量时间优化 API 以供人类使用，即便我们正进入一个 API 完全由我们的机器代表我们使用的时代。我们的 LLM 是在开发者的历史数据上训练出来的，在它们能够自我训练之前，我们过去那些尚未被完全阐明的规范仍然有其价值。

Go 是一门编译型语言，其编译器速度很快。依赖相对容易安装和管理。这门语言相对高效，但最重要的是，它易于对程序进行性能分析和效率改进，而智能体很擅长做这件事。

它也有弱点。随着时间推移，构建缓存会在 CI 机器上不断增长，需要一些繁琐的管理。一些流行的第三方依赖不知为何既非常臃肿，又缺少功能。如果你的程序很成功并形成了热点路径，你就需要做一些工作来减少这些热点路径上的堆分配（超出编译器通过自动栈分配转换为你所做的那部分）。这些对开发者来说是可管理的，对智能体来说也是可管理的。

总体而言，Go 是一门不完美的编程语言，与其他所有不完美的语言一同位列万神殿，各有取舍。它的取舍大体上是务实的。简而言之：你读过的所有支持或反对各种语言的传统论点依然适用。

所以我们决定押注 Go。它对我们有利，我们认为它对智能体也有利。到目前为止，用 Shelley 开发 Shelley 一直是一种享受。如果你把它拿去并改造成你自己的，我们希望你也同样感受到这一点。

Web UI 是 Vue

Web UI 是个例外：它是一个用 TypeScript 编写的 Vue 3 应用，基于 PrimeVue 组件构建，位于 ui/ 下。它从 ui/src/vue/main.ts 开始，组件位于 ui/src/vue/components/ 中。esbuild 将其打包成 ui/dist/，由 Go 二进制文件嵌入，因此 Shelley 仍然以单文件形式发布；在浏览器中，UI 通过一个 JSON API 和一个长期存在的服务器发送事件流与服务器通信。

Shelley 会一直用 Go 编写吗？

大概不会！

传统上，软件项目很少改变其编写所用的语言。即便是像 GCC 从 C 转向 C++ 这样的“轻松”迁移，也是巨大的工程。像 Go 编译器工具链从 C 转向 Go 这样的项目，是我见过的最棘手的工程之一。

但现在，借助智能体，迁移语言对大型项目来说已经变得可行。

今天我们没有明显会选择将 Shelley 迁移到的语言。然而，我认为我们极不可能已经看到了编程语言发展的终点。一旦这场最初的尖端模型竞赛平息下来，编程模型出现分化，人们将开始结合训练模型来构建编程语言。这将引入一个编程语言的新时代（这些语言有可能在我们人类程序员看来十分陌生），随着技术的变化，我们应该重新考虑。