Nim语言之父对于1.0版本的个人感言

23 September 2019 Andreas

功夫不负有心人，我们终于做到了！
万众瞩目的 1.0 版本来了。

当我开始 Nim 开发时， 我想的是一个编译成 C 的不超过2万行代码的简单语言。 核心指导方针是 Nim 是 具有宏系统 、 用以 扩展 微核心缺少的所有特性的 轻量 语言。

当前的编译器加上它使用的标准库， 不完全统计有大概14万行代码， 支持了几乎所有的操作系统和CPU架构， 可以编译成 C++ 和 JavaScript， 并且 Nim 的元编程能力是数一数二的。 语言不再轻量， 也证明了元编程无法取代所有现代语言需要的构建环节。

例如， 当 Nim 用 宏系统 实现 async 时， 宏系统需要能够将代码编译成状态机。 这些状态机需要 goto 和获取环境变量的方式。 所以Nim的内核需要增加 “闭包迭代器” 来实现。

此外， 我们还没有真正了解如何 利用宏系统提供在类型系统层面的可扩展性， 所以Nim的内核需要泛型和泛型约束。

关于开发进展

之前说过， 我对语言开发进展表示满意， 版本 1.0 意味着我们现在有不同的开发进展： 之前的Nim被太多 “最少的惊喜原则” 推动， 导致每个人可以说 “额，我认为这本来应该工作…”， 然后随后实现的时候，还带来了很多特殊情况。 这些特殊情况可能失控并让系统 更难 理解，最终产生了新的……“惊喜”。 从 1.0 版本开始我们遵循 “规范优先” 的开发： 先写RFC，之后讨论，再写规范，再实现，再在实现的过程中观察 规范 所带来的反馈。

对，我知道规范/手册有一些疏漏和bug，但这种现状正在改善。 新的 “析构器” 语言特性也是遵循 规范先行 的思想开发的， 哪怕规范本身还有瑕疵，效果也能好很多，并且能产生更高质量的结果。

Nim 的未来

我们想把重心放在Nim的工具上， 包括 Nimsuggest (一个跨编辑器的 Nim 代码补全引擎)， Nimble （ Nim 的包管理器)， 和 Nimpretty（ Nim 的源代码格式化工具）。 从我个人的角度，我认为 “增量编译”(IC) 会是 Nim 编译器下一个大的里程碑。 IC 将会进一步压缩 Nim 已经很快的编译时间， 加快对宏扩展和其他构造结果的缓存。

关于 concepts 和 owned: 有人说，这两个特性必须和 1.0 版本一起发布， 因为它们改变了 Nim 在实际开发过程中的编写方式。 但，恕不敢苟同，即使没有 concept ，语言仍然可以很好地运作， 而且尽管现有的 concepts 语法和语义亟待改善，但也是能用的。 现在还不清楚我们是否最终会在 Nim 中使用 owned ，我也有其他的想法来改进nim的内存管理。

不过这都不重要。v1 版本的宗旨是交付我们有的，不是我们想要的。 前途是光明的，1.0 版本只是一个开始。

就像一场婚姻，婚礼只是开始。