RustPython

Original Article ↗ Hacker News Discussion ↗

A Rust-based implementation of the Python 3 interpreter, RustPython, is drawing interest for use as an embedded scripting engine in Rust applications and for compiling Python to WebAssembly to run in browsers or constrained environments. Commenters highlight its benefits—memory safety, easy Rust integration, potential WASM deployment—alongside significant current limitations, including incomplete standard library support, lack of CPython C-extension compatibility (so no NumPy/SciPy), and performance that lags behind CPython. The debate also surfaces broader frustrations with Python’s packaging and environment management, and contrasts Python’s ecosystem-driven value with Rust’s focus on language safety and tooling.

RustPython Goals and Status

  • Python 3 interpreter written in Rust; can be embedded into Rust apps and compiled to WebAssembly.
  • Project is active on GitHub despite a quiet blog; recent releases and commits noted, though some see contribution slowdown.
  • Explicitly marked as “development phase”: not recommended for production; supports ~half the standard library.
  • Binary size impact is substantial but seen as acceptable: a “hello world” with RustPython embedded is ~15 MB vs ~0.4 MB in pure Rust.

Embedding and Scripting Use Cases

  • Main attraction: using Python as an embedded scripting language inside Rust (or other native) programs.
  • People compare with Lua, Rhai, Starlark, JS engines, and Rust-embedded languages (rhai, dyon, duckscript, rune) for configuration and plugins.
  • Experience from a C++ product embedding CPython: easy binding, but hard in practice (threading, startup cost, teardown crashes, packaging vs system Python). Some fear similar Rust+Python maintenance complexity.

Ecosystem & C-Extension Compatibility

  • RustPython currently does not support CPython’s C-extension API; packages like NumPy would need custom ports.
  • Broader point: alternative interpreters often lose access to the huge C-extension ecosystem; this sharply limits applicability.
  • HPy is mentioned as a potential cross-implementation C-API/ABI that could help RustPython and PyPy.

Python Packaging and Tooling Pain

  • Strong recurring complaint: dependency and environment management (pip/pip3, venv, conda, pyenv, OS vs user installs, Windows vs Linux) is confusing and fragile, especially for infrequent users.
  • Some propose minimal, built-in workflows using python -m venv and local pip, plus tools like Rye.
  • Others argue the situation still has too many “gotchas” (e.g., Windows Store Python, missing launchers), especially compared with cargo, npm, or Go tooling.

Performance and WASM Concerns

  • Benchmarks on naive Fibonacci show RustPython ~11× slower than CPython; experimental JIT helps but is incomplete (e.g., recursive functions).
  • WebAssembly use is attractive (Python in the browser, ICP, Kybra), but cold-start times and large WASM blobs (≈10–22 MB) are concerns.
  • Some say this is acceptable for many business scripts; others warn startup can take seconds and may be impractical for many apps. Tools like Wizer/partial evaluation are mentioned as mitigations.

Third-Party Interpreters in Practice

  • PyPy, Jython, IronPython, Stackless Python, MicroPython, GraalPy are cited, with real-world uses (batch jobs, trading systems, tools scripting, games).
  • PyPy is praised as underused and very fast for pure Python, but limited by C-extension compatibility and ecosystem inertia.

Language Tradeoffs: Python vs Rust

  • Debate over Python’s value: some see the language as “poor” and the ecosystem as the main asset; others praise its ergonomics and “just get things done” nature.
  • Rust is praised for safety, expressiveness (sum types, traits), tooling (cargo), and deployment simplicity; some claim they are more productive in Rust even ignoring performance.
  • Counterpoint: many workloads don’t need Rust’s performance; Python remains dominant for rapid development and ML/science.