这个世界上不是所有的事情都唯快不破，比如男人就不能太快。

但是脚本语言是不是应该追求快，那可能需要分析分析。

Python 最初的价值是用来做系统脚本，说人话就是干脏活当苦力。本着这样的实用目的，当然是怎么舒服怎么来，这门语言的设计基本都是以爽为主。问题在于，爽文人人爱读，但是很少有人拿爽文当圣经。爽语言人人爱用，却总是有人对爽语言顶礼膜拜。

然而，追求永恒性的同时也要尊重时代性的选择，因为时代性的因素关系到生存问题，可一个时代终将过去，那个时候还能继续保留下来的只能是具有某种永恒性的东西。所谓积累，莫非如此。

Python 的流行度使得它成为了某种流量密码，写 100 篇有一手资料的业内深度分析，远不如写一篇跟 Python 相关的文章。MIT 的人似乎也不能免俗，他们最近发布了一个 Python 的 AOT 编译器实现 Codon，从这个名称可以看出来，这似乎最初是为了生物信息领域的科学计算而设计的，因为这类计算不同于产业界的工程化，他们不是很在意动态语言引以为豪的各种动态特性，他们要的是比爽更爽，甚至忽略工程化——科研嘛，必然还是喜欢飘在天上的。之所以选择 Python，理由说到底还是流量密码，受欢迎很重要，哪怕做大众工具一分钱都挣不了。

至于 AOT 这个说法，在这里更准确点应该叫 full AOT，就是基本把运行时环境全部弄掉了，纯静态的本地代码速度快。当然非要较真的话，还是有 GC 的，用上了性能更好的 conservative GC（Boehm-Demers-Weiser conservative garbage collector），这种 GC 的好处是栈操作不用维护一个局部变量的列表，相当于省了局部变量释放时候的运行时开销，缺陷就是不一定保证全部回收，不过反正泄漏的也极少——如果不放心，那么想一想主流 JS 都部分使用了这种回收方式。

当然较真 full AOT 绝对意义上有没有运行时可能意义不大，即便是 C 也有运行时 crt0，一般知道的人也不多。

Codon 的架构也不复杂，主要工作量就在前端，lexer/parser 和 type checking 占大头。语法基本上对标 CPython，但实际上算是一个 DSL（领域专用语言）。Full AOT 就必须把类型全部静态化处理，自然就需要编译时的 type checking，要说有什么出彩的地方，就是用了 HM 类型推导自动声明类型，不用开发者手写类型声明（效果如何有待他人评测）。至于中端的优化部分，基本乏善可陈，作者的意图还是直接扔给 LLVM 去优化，最后还能自动获得一个支持 WASM 的卖点。

要不说这年头写编译器简单呢，很多所谓优化编译器都是把优化扔给 LLVM，如果连这种程度的编译器都做不出来，常年只能停留在 PPT 里，那只可能是骗经费了。当然，如果你觉得未来就是靠 LLVM 就行了，那不妨回想一下前文，时代性和永恒性。

抛开一些杂音，Codon 还是值得期待的，因为它已经有商业案例了。这种工具链的商业模式在国内是几乎不存在的，算是高校、社区、产业界高度结合发展的一个小案例，值得玩味，但别多想。