用 LLM 移植 20 种语言后：代码越简洁，AI 越好用

一位独立开发者近日完成了一项规模不小的实测：他将一套用 Crystal 编写、包含 51 个用例（覆盖排序、解析、算法、压缩等）的基准测试套件，借助 LLM 逐一移植到另外 19 种编程语言，整个过程历时约两个月。项目最终成果已公开发布在 LangArena，最初目的是横向比较各语言的运行性能与内存占用。然而在整理代码量、编译时间等数据的过程中，他意外发现一项指标与「用 LLM 编程的实际体验」高度吻合。

实验背景与方法

作者将同一套基准测试在 20 种语言中分别实现，并对源代码体积、gzip 压缩后体积、行数等进行了统一度量。原始动机是性能基准，但语言移植过程本身引入了第二个维度：哪些语言更适合让 LLM 来生成和修改代码。

「表达力」指标的设计

作者设计了一张「Expressiveness（表达力）」对比表，核心公式为：

• Size：全部源文件体积（KB）
• Gzip Size：gzip 压缩后体积（KB）
• Boilerplate = Size / Gzip Size，越低代表冗余越少
• Expressiveness Score = (Boilerplate vs Avg) × (Lines vs Avg)^1.5，越低代表越简洁

按这一指标，排名第一的是 Crystal（比平均简洁约 44.8%），而垫底的 Zig 则比平均冗长 176.2%。

gzip 视角：区分冗余与必要代码

指标的关键洞察来自 gzip：它只能压缩重复模式，对 Result、Option、生命周期这类「有意义但独特」的语法构造无能为力。以 Rust 和 Zig 为例：

• Rust：164 KB 源码 → 31 KB gzip，Boilerplate = 5.3，比平均简洁 29%
• Zig：288 KB 源码 → 44 KB gzip，Boilerplate = 6.6，比平均冗长 176%

Rust 的源码与 gzip 后体积均小于 Zig，说明它的冗余仪式更少，而安全相关特性并未被指标惩罚。同平台语言对比同样合理：Kotlin 比 Java 简洁 22%，Scala 再进一步到 41.9%。

与 LLM 协作体验的高度吻合

作者在移植过程中观察到一个「几乎完美」的对应关系：表达力排名靠前的语言，与 LLM 协作时明显更顺畅。

• Scala、Nim、Go：AI 生成的代码通常一次就能跑通；即便需要多轮迭代，调整也很快收敛。
• Odin、C、Zig：代码量大，LLM 经常丢失上下文，典型循环是「跑代码→段错误→定位→修几处→新错误再现」。
• Zig 还因 API 变动让 LLM 生成了旧版本代码，看起来正确却无法编译。

作者据此提出一个朴素但有数据支撑的观点：写越多代码意味着越难在脑中维护整体程序、越多 bug 藏身处、越难让 LLM 跟上、以及越慢的开发节奏。这并不意味着「表达力」是衡量语言好坏的唯一标尺，但作为「代码密度」或「书写效率」的代理指标，它对 LLM 时代的开发者选型具有可参考价值。