RustPython

原文 ↗ Hacker News 讨论 ↗

RustPython 是一种用 Rust 实现的 Python 3 解释器，因可作为 Rust 应用中的嵌入式脚本引擎，以及可将 Python 编译为 WebAssembly 以在浏览器或受限环境中运行而受到关注。评论者一方面强调其优势——内存安全、与 Rust 的易集成、潜在的 WASM 部署能力——另一方面也指出其当前的重大限制，包括标准库支持不完整、缺乏对 CPython C 扩展的兼容性（因此无法使用 NumPy/SciPy），以及性能落后于 CPython。讨论还引出了对 Python 打包和环境管理的更广泛不满，并将 Python 以生态为核心的价值与 Rust 以语言安全和工具链为核心的价值进行了对比。

RustPython 目标与现状

  • 用 Rust 编写的 Python 3 解释器；可嵌入到 Rust 应用中，并可编译为 WebAssembly。
  • 尽管博客更新较少，该项目在 GitHub 上仍然活跃；近期有发布和提交记录，不过也有人认为贡献速度有所放缓。
  • 明确标注为“开发阶段”：不建议用于生产；支持约一半的标准库。
  • 对二进制体积的影响相当大，但被认为可以接受：嵌入 RustPython 的“hello world”约为 15 MB，而纯 Rust 约为 0.4 MB。

嵌入与脚本化使用场景

  • 主要吸引力：在 Rust（或其他原生）程序中将 Python 作为嵌入式脚本语言使用。
  • 人们将其与 Lua、Rhai、Starlark、JS 引擎，以及面向 Rust 的嵌入式语言（rhai、dyon、duckscript、rune）进行比较，用于配置和插件。
  • 来自某个嵌入 CPython 的 C++ 产品的经验：绑定很容易，但实际使用中很难——包括线程、启动成本、退出时崩溃、打包与系统 Python 的问题。有人担心 Rust+Python 也会有类似的维护复杂度。

生态系统与 C 扩展兼容性

  • RustPython 目前不支持 CPython 的 C 扩展 API；像 NumPy 这样的包需要专门移植。
  • 更广泛的观点是：替代解释器往往会失去对庞大 C 扩展生态的访问，这会严重限制适用范围。
  • 文中提到 HPy 可能成为一种跨实现的 C-API/ABI，有望帮助 RustPython 和 PyPy。

Python 打包与工具链痛点

  • 一个反复出现的强烈抱怨是：依赖和环境管理（pip/pip3、venv、conda、pyenv、系统安装与用户安装、Windows 与 Linux）令人困惑且脆弱，尤其对不常使用者而言。
  • 有人建议采用最小化、内建的工作流：使用 python -m venv 和本地 pip，再配合 Rye 之类的工具。
  • 也有人认为这套体系仍有太多“坑”（例如 Windows Store Python、缺少启动器），尤其与 cargo、npm 或 Go 的工具链相比更明显。

性能与 WASM 相关担忧

  • 在朴素的 Fibonacci 基准测试中，RustPython 比 CPython 慢约 11 倍；实验性 JIT 有帮助，但尚不完整（例如递归函数）。
  • WebAssembly 的用途很有吸引力（在浏览器中运行 Python、ICP、Kybra），但冷启动时间和较大的 WASM 二进制体积（约 10–22 MB）令人担忧。
  • 有人认为这对许多业务脚本来说是可以接受的；也有人警告启动可能需要数秒，并且对很多应用而言不切实际。文中提到 Wizer/部分求值等工具作为缓解手段。

实践中的第三方解释器

  • 文中提到 PyPy、Jython、IronPython、Stackless Python、MicroPython、GraalPy，并列举了现实用途（批处理作业、交易系统、工具脚本、游戏）。
  • PyPy 被称赞为未被充分使用且在纯 Python 场景下非常快，但受限于 C 扩展兼容性和生态惯性。

语言取舍：Python vs Rust

  • 关于 Python 价值的争论：有人认为这门语言“很差”，生态才是主要资产；也有人赞赏它的易用性和“先把事情做完”的特性。
  • Rust 因安全性、表达能力（和类型、trait）、工具链（cargo）以及部署简洁性而受到称赞；有人甚至表示，即使不考虑性能，他们在 Rust 中也更高效。
  • 反方观点：许多工作负载并不需要 Rust 的性能；Python 仍然在快速开发和机器学习/科学领域占主导地位。