Lua5.1为何仍是主流？探索其持久流行的原因

严格来说，LuaJIT 的流行程度远超 Lua 5.1。LuaJIT 完全兼容 Lua 5.1，并支持大部分 Lua 5.2 的特性、部分 Lua 5.3 的特性以及少量 Lua 5.4 的功能。此外，LuaJIT 还引入了一些独有的 FFI（Foreign Function Interface）扩展，这些特性使其实际上已经成为一个独立的 Lua 版本。LuaJIT 的主要维护者 Mike Pall 对 Lua 官方团队在后续版本中做出的一些破坏性改动持强烈反对态度。因此，LuaJIT 很可能永远不会正式支持 Lua 5.3 及更高版本，尽管它通过扩展实现了一些特性，例如 UTF-8 支持和位操作。争议最大的改动之一是 Lua 5.3 中引入的 64 位整数支持，以及 Lua 5.4 中新增的分代垃圾回收机制（GC）。分代 GC 的引入与 LuaJIT 当前的垃圾回收模型直接冲突，而 64 位整数支持则破坏了 LuaJIT 中广泛使用的一种优化技术——NaN Tagging。这种技术将指针编码为 IEEE 754 标准中的 NaN 值，从而使原始值（primitive value）和装箱值（boxed value）可以存储在相同的结构中，显著提高了效率。这种优化方法历史悠久且应用广泛，甚至在上世纪八九十年代的部分 LISP 实现以及现代的 Wren 编程语言中都有所体现。然而，64 位整数的支持显然会对这种优化造成干扰。至于垃圾回收机制的改进，LuaJIT 当前使用的 GC 算法效率并不高，几乎没有进行太多优化，其基本原理与 Lua 5.1 的分步 GC 类似。几年前，维护者曾提到计划开发一种更强大的分代 GC，但进展极为缓慢，目前这项工作几乎已经停滞。顺便一提，LuaJIT 的代码结构和风格复杂混乱，在 JIT 编译器领域中也算得上是黑魔法的代表，即使是在以各种 hack 和 trick 著称的 JIT 编译器家族中也显得尤为突出。这可能是导致 LuaJIT 缺乏开发人员的重要原因之一。例如，有人曾尝试为其添加对 RISC-V 架构的支持，但最终被复杂的代码劝退。当然，也有第三方开发者试图改进 LuaJIT，甚至从头开始构建一个新的 JIT 编译器。然而，这些项目大多处于玩具阶段，或者已经被开发者放弃。相对活跃的只有一个由 OpenResty 团队维护的分支。