let-go: 用 Go 实现 7ms 冷启动的 Clojure 方言

在 Go 语言生态中，将 Lisp 方言移植到非 JVM 平台一直是编译器工程的难点。nooga 的 let-go 项目提供了一个可行的答案：用一个自包含的字节码虚拟机，在 10MB 的二进制包中实现了 95.4% 的 Clojure 兼容性，且冷启动时间仅为 7ms。这个数字比 GraalVM 原生化的 Babashka 快 3 倍，比传统 JVM 上的 Clojure 快 48 倍。本文从编译策略与运行时设计两个维度，深入拆解 let-go 达成这一性能目标的关键技术路径。

预编译字节码：跳过解析的开销

let-go 实现快速启动的核心手段并非运行时优化，而是在分发前完成尽可能多的工作。项目定义了 LGB（let-go Bytecode）格式，用于存储预先编译好的字节码。用户编写 .lg 源文件后，通过 lg -c output.lgb input.lg 命令将源码编译为字节码文件；运行 lg output.lgb 时，VM 直接加载预编译结果，跳过了 Reader、Parser 与 Compiler 的全部初始化开销。

这一策略与 GraalVM Native Image 预热思路相似，但实现路径更轻量：Native Image 需要在构建时执行 JVM 的 AOT 编译与 escape analysis，而 let-go 的预编译只需一个独立的编译阶段。源码中的宏展开、函数闭包捕获、命名空间依赖图解析都在 -c 阶段完成，运行时的 requestAnimationFrame（约 16ms）内甚至还有 10ms 的余量。设计文档中明确将此列为一项非正式目标：在单帧内完成整个运行时引导。

更进一步的发布形式是 -b 参数，它将编译后的字节码直接追加到 let-go 可执行文件的末尾，生成一个无需任何外部依赖的独立二进制。分发时只需复制一个文件，运行时无需加载任何动态库或字节码文件。

字节码虚拟机：与树遍历解释器的性能差距

let-go 的性能优势在 benchmark 中最直观地体现为与 Joker 的对比。Joker 是另一个 Go 语言实现的 Clojure 方言，采用树遍历（tree-walk）解释器架构 —— 每条 S 表达式都在运行时被解析为 AST 节点并立即求值。而 let-go 在多数计算密集型任务上比 Joker 快 10 倍以上，这一差距根本性地来自于架构选择。

树遍历解释器在每次函数调用时都需要重新解析参数表达式、构造中间 AST、查找变量绑定。这些重复工作在短时任务中占比极高，使得 Joker 在 fib(35) 等计算场景下性能受限。字节码虚拟机则将源码一次性编译为顺序执行的指令序列，函数调用仅涉及栈帧的 push/pop，变量查找通过常量池索引完成，没有中间 AST 构造的开销。

从基准测试数据来看，let-go 在 map/filter 与 transducer 管道任务上达到 8ms，而 Babashka 需 19ms（2.4 倍差距）。在递归密集型的 fib 场景中，let-go 与 Babashka 的差距缩小到 4% 以内 —— 两者都受益于函数调用的低开销。这说明当编译器前端完成足够多的静态分析后，运行时性能主要取决于函数调用与数据抽象的底层成本，而 Go 作为编译型语言的静态调用约定恰好为此提供了良好的基础。

运行时初始化：分层常量池与命名空间按需加载

即便不做预编译，let-go 在冷启动场景下的初始化开销也经过了精心控制。编译器包中的 CoreConsts() 函数返回一个全局常量池，该池在运行时引导阶段一次性填充，并作为用户代码编译时的父池使用。这种分层常量池设计意味着：核心语言常量的符号表在启动时只构建一次，后续每个命名空间的编译都共享同一个父池，只在自己的层中追加新定义的常量。

命名空间的惰性加载机制进一步压缩了启动时间。README 中提到运行时引导可以在 requestAnimationFrame 内完成，这意味着在 60fps 的动画帧预算（约 16.67ms）中还有余量。实现这一点的关键在于：标准库中的核心命名空间（如 clojure.core）的函数体并非在引导时求值，而是以字节码块的形式预存在常量池中；首次调用时才触发惰性链接。这与 JVM 的类延迟加载不同 ——JVM 的类加载涉及字节码验证与反射元数据构造，而 let-go 的惰性链接仅涉及函数指针的解析，没有安全验证的开销。

PrecompiledNSChunk(name) 函数提供了对预编译命名空间块的直接访问，允许运行时在已知需要某个命名空间时快速注入其字节码，而无需再次调用通用的编译流程。这是一种以空间换时间的策略：内存中保留了更多已编译的代码块，但避免了重复解析与编译的 CPU 开销。

Go 互操作：结构体与通道的双向桥接

let-go 的定位不是纯粹的语言实验，而是一个可嵌入 Go 应用的脚本层。在 pkg/api 与 pkg/vm 包中，项目提供了结构体注册、函数导出与通道桥接三类互操作能力。

vm.RegisterStruct[T] 将 Go 结构体注册为 let-go 的记录类型，并在注册时缓存字段到字节码偏移的转换器。转换器在首次访问时构造一次，后续字段访问直接通过偏移量读取，完全绕过了反射。这对于频繁访问 Go 结构体字段的热路径尤其重要。

双向通道桥接则利用了 Go 通道与 let-go 核心异步通道的语义兼容性。Go 端的 chan T 可以直接赋值给 let-go 的 vm.Chan 变量，在 go 块中使用 <! 与 >! 操作符时无需额外适配层。这在事件流处理与后台任务编排场景中降低了桥接层的复杂度。

约束与已知权衡

7ms 启动时间的代价并非不存在。项目文档明确列出了几项已知的语义偏离：通道操作全部是阻塞的（Go 通道没有 IOC 状态机），Refs 与 STM 未实现（以 atoms 和 channels 替代），BigDecimal 完全缺失（数值塔为 int64 + float64 + BigInt）。此外，+/-/* 等基础运算在 int64 溢出时静默环绕而非提升为 BigInt—— 这意味着数值精度在溢出边界处与标准 Clojure 不同。

这些约束中有相当一部分源于 Go 语言本身的限制：Go 没有协程的 IOC 机制，所以 go 块使用真实的 goroutine 实现，这与 Clojure core.async 的反转控制状态机在调度语义上有本质区别。项目选择用 "更 cheap 但语义不同" 的方式处理这种差异，而非尝试在 Go 上模拟 JVM 的调度器。

数字溢出的处理则更多是工程优先级的选择：检测每一次整数运算是否溢出并决定是否提升为 BigInt 需要在运行时插入大量的条件分支，严重拖累基础数值运算的性能。在大多数短时脚本场景中，溢出并不是高频事件，静默环绕是一个务实的折中。

工程视角：轻量化分发与快速反馈循环

从工程组织角度看，let-go 的价值主张在轻量化与快速反馈两个维度。

轻量化维度：10MB 的二进制与 14MB 的空闲内存使得 let-go 可以被打包进容器镜像或作为 CLI 工具分发，而不需要安装 JDK 或 GraalVM。在 CI/CD 流水线中，这意味着 runner 环境的准备时间可以从分钟级缩短到秒级。-b 生成的独立可执行文件进一步简化了分发 —— 没有外部运行时依赖，没有字节码路径问题，直接复制即可运行。

快速反馈维度：7ms 的冷启动时间使得 REPL 交互式开发变得实际可行。在 JVM 上，每次表达式求值都需要承担数百毫秒的启动成本，开发者在 REPL 中的等待会打断思维流。let-go 的冷启动时间使得 "写几行代码，立即运行观察结果" 的循环可以在毫秒级完成，这与现代动态语言的交互式开发体验更为接近。

总结

let-go 的 7ms 启动时间并非单一优化手段的结果，而是编译策略与运行时设计协同优化的综合产物。预编译字节码消除了解析开销，分层常量池减少了引导时的符号构建成本，惰性链接将命名空间初始化推迟到实际使用时刻，字节码 VM 则将运行时函数调用的开销降到接近静态编译的水平。在 Go 语言提供的编译器工具链与 goroutine 调度器的支撑下，这些策略共同支撑了一个可以在 10MB 包内完整运行的 Clojure 方言。

项目地址：github.com/nooga/let-go，采用 MIT 许可证，支持 Linux、macOS、Windows 多平台。

资料来源：项目 README 与 benchmark 数据（Apple M1 Pro 环境）。

compilers