最近读到一篇关于 Rust 插件系统设计的文章。作者 fmiras 对几种常见方案进行了比较原生动态库、嵌入式脚本语言、WebAssembly、表达式引擎。最后他的推荐方向很有意思如果要给 Rust 程序增加插件能力脚本语言通常是更值得优先考虑的方案而在 JavaScript 方案里他更推荐 QuickJS而不是 V8。这个结论有点出乎意料。因为说到嵌入式脚本语言过去三十年的答案几乎一直是 Lua。Nmap、Wireshark、Neovim以及大量游戏引擎都证明过 Lua 作为插件语言的可靠性。那么问题来了既然 Lua 已经这么成熟为什么还会有人考虑 QuickJS这背后真正变化的不是哪门语言更先进而是插件系统面对的人变了。Lua 为什么能成为过去三十年的答案Lua 的成功并不是因为它拥有最复杂的能力。恰恰相反它成功的原因是克制。Lua 从设计之初就是为了嵌入其他程序体积小、容易集成、语法简单、宿主程序可以控制暴露给脚本的能力。对于软件作者来说这意味着可以很低成本地给程序增加扩展能力。Nmap 的 NSENmap Scripting Engine使用 Lua 编写网络扫描脚本已经运行多年。Wireshark 支持 Lua 编写协议解析器让用户可以扩展自己的分析能力。Neovim 将 Lua 作为主要插件语言让编辑器生态从 Vimscript 迁移到更现代的脚本环境。甚至 Rust 编写的终端文件管理器 yazi也选择 Lua 作为插件接口。这些案例说明了一件事Lua 不是一个”老语言”它是一个已经被大量软件验证过的嵌入式扩展方案。那为什么还需要 QuickJS因为插件作者正在变化。过去设计插件系统时开发者面对的问题是”我应该给用户提供哪一门适合嵌入的语言”Lua 几乎是最好的答案。但今天很多项目面对的是另一批开发者他们可能每天使用 JavaScript、TypeScript、Node.js、Web 工具链。对于他们来说Lua 不是难学但它是一门额外需要学习的语言。于是 QuickJS 提供了一种新的可能让插件作者继续使用 JavaScript而宿主程序又不需要引入完整的浏览器级运行环境。这才是 QuickJS 真正有意思的地方。它不是为了证明 Lua 不够好而是在解决另一个问题如何让更多已经会 JavaScript 的开发者参与软件扩展。QuickJS 和 V8 的区别不只是性能既然选择 JavaScript为什么不用 V8因为 V8 解决的是另一个问题。V8 是为了让 JavaScript 在浏览器和 Node.js 中高速运行拥有即时编译、高度优化的执行引擎、完整运行时。这些能力让 V8 非常强大但也带来了更高的嵌入成本。而插件系统很多时候并不需要极限性能。一个插件可能只是修改配置、增加一个命令、扩展一个工作流、添加一个自动化动作。这种场景下运行时大小、启动速度、集成难度可能比峰值性能更重要。QuickJS 选择了另一条路线它没有追求成为最快的 JavaScript 引擎而是成为一个更容易嵌入的软件组件。QuickJS 值得关注的三个原因JavaScript 是很多开发者的共同语言插件生态最大的成本不只是技术成本还有人的成本。一门语言越接近插件作者已有的技能生态越容易建立。过去 Lua 降低了”嵌入脚本”的门槛今天 QuickJS 降低的是”让 JavaScript 开发者参与软件扩展”的门槛。它比完整 JavaScript 运行时更适合嵌入很多软件并不需要一个完整 Node.js它们需要的只是”执行一段脚本并让脚本调用几个受控接口”。QuickJS 的定位刚好符合这种需求。没有 JIT 也是一种取舍很多人看到 JavaScript 引擎会自然想到性能。但插件系统的重点通常不是跑分。没有 JIT意味着运行时更简单初始化成本更低也减少了一部分复杂执行路径。对于很多扩展场景这是一种合理交换牺牲部分极限性能换取更容易嵌入。插件语言没有赢家只有不同取舍场景选择需要长期稳定的嵌入式插件生态Lua插件作者主要使用 JavaScript / TypeScriptQuickJS需要更强隔离能力WebAssembly只执行规则和过滤逻辑CEL 等表达式语言极致性能接受复杂度原生动态库没有一种方案适合所有情况。Lua 的优势是三十年的生产验证。QuickJS 的机会是连接新的开发者群体。写在最后过去三十年Lua 证明了一件事插件语言最重要的不是语法有多漂亮而是能不能长期陪伴一个系统成长。QuickJS 的出现则说明了另一件事插件生态的竞争对象不只是技术也是开发者。以前软件需要问”哪门语言最适合作为插件语言”现在它还需要问”我的插件作者已经会什么”。Lua 已经是成熟答案。而 QuickJS可能是下一批工具值得尝试的方向。它不是替代 Lua它只是在现代 JS 语境下让 Rust 项目可以极低成本地接住 JavaScript 庞大的开发者红利。
最近读到一篇关于 Rust 插件系统设计的文章。作者 fmiras 对几种常见方案进行了比较原生动态库、嵌入式脚本语言、WebAssembly、表达式引擎。最后他的推荐方向很有意思如果要给 Rust 程序增加插件能力脚本语言通常是更值得优先考虑的方案而在 JavaScript 方案里他更推荐 QuickJS而不是 V8。这个结论有点出乎意料。因为说到嵌入式脚本语言过去三十年的答案几乎一直是 Lua。Nmap、Wireshark、Neovim以及大量游戏引擎都证明过 Lua 作为插件语言的可靠性。那么问题来了既然 Lua 已经这么成熟为什么还会有人考虑 QuickJS这背后真正变化的不是哪门语言更先进而是插件系统面对的人变了。Lua 为什么能成为过去三十年的答案Lua 的成功并不是因为它拥有最复杂的能力。恰恰相反它成功的原因是克制。Lua 从设计之初就是为了嵌入其他程序体积小、容易集成、语法简单、宿主程序可以控制暴露给脚本的能力。对于软件作者来说这意味着可以很低成本地给程序增加扩展能力。Nmap 的 NSENmap Scripting Engine使用 Lua 编写网络扫描脚本已经运行多年。Wireshark 支持 Lua 编写协议解析器让用户可以扩展自己的分析能力。Neovim 将 Lua 作为主要插件语言让编辑器生态从 Vimscript 迁移到更现代的脚本环境。甚至 Rust 编写的终端文件管理器 yazi也选择 Lua 作为插件接口。这些案例说明了一件事Lua 不是一个”老语言”它是一个已经被大量软件验证过的嵌入式扩展方案。那为什么还需要 QuickJS因为插件作者正在变化。过去设计插件系统时开发者面对的问题是”我应该给用户提供哪一门适合嵌入的语言”Lua 几乎是最好的答案。但今天很多项目面对的是另一批开发者他们可能每天使用 JavaScript、TypeScript、Node.js、Web 工具链。对于他们来说Lua 不是难学但它是一门额外需要学习的语言。于是 QuickJS 提供了一种新的可能让插件作者继续使用 JavaScript而宿主程序又不需要引入完整的浏览器级运行环境。这才是 QuickJS 真正有意思的地方。它不是为了证明 Lua 不够好而是在解决另一个问题如何让更多已经会 JavaScript 的开发者参与软件扩展。QuickJS 和 V8 的区别不只是性能既然选择 JavaScript为什么不用 V8因为 V8 解决的是另一个问题。V8 是为了让 JavaScript 在浏览器和 Node.js 中高速运行拥有即时编译、高度优化的执行引擎、完整运行时。这些能力让 V8 非常强大但也带来了更高的嵌入成本。而插件系统很多时候并不需要极限性能。一个插件可能只是修改配置、增加一个命令、扩展一个工作流、添加一个自动化动作。这种场景下运行时大小、启动速度、集成难度可能比峰值性能更重要。QuickJS 选择了另一条路线它没有追求成为最快的 JavaScript 引擎而是成为一个更容易嵌入的软件组件。QuickJS 值得关注的三个原因JavaScript 是很多开发者的共同语言插件生态最大的成本不只是技术成本还有人的成本。一门语言越接近插件作者已有的技能生态越容易建立。过去 Lua 降低了”嵌入脚本”的门槛今天 QuickJS 降低的是”让 JavaScript 开发者参与软件扩展”的门槛。它比完整 JavaScript 运行时更适合嵌入很多软件并不需要一个完整 Node.js它们需要的只是”执行一段脚本并让脚本调用几个受控接口”。QuickJS 的定位刚好符合这种需求。没有 JIT 也是一种取舍很多人看到 JavaScript 引擎会自然想到性能。但插件系统的重点通常不是跑分。没有 JIT意味着运行时更简单初始化成本更低也减少了一部分复杂执行路径。对于很多扩展场景这是一种合理交换牺牲部分极限性能换取更容易嵌入。插件语言没有赢家只有不同取舍场景选择需要长期稳定的嵌入式插件生态Lua插件作者主要使用 JavaScript / TypeScriptQuickJS需要更强隔离能力WebAssembly只执行规则和过滤逻辑CEL 等表达式语言极致性能接受复杂度原生动态库没有一种方案适合所有情况。Lua 的优势是三十年的生产验证。QuickJS 的机会是连接新的开发者群体。写在最后过去三十年Lua 证明了一件事插件语言最重要的不是语法有多漂亮而是能不能长期陪伴一个系统成长。QuickJS 的出现则说明了另一件事插件生态的竞争对象不只是技术也是开发者。以前软件需要问”哪门语言最适合作为插件语言”现在它还需要问”我的插件作者已经会什么”。Lua 已经是成熟答案。而 QuickJS可能是下一批工具值得尝试的方向。它不是替代 Lua它只是在现代 JS 语境下让 Rust 项目可以极低成本地接住 JavaScript 庞大的开发者红利。
