RustPython

https://rustpython.github.io/

by BerislavLopac • 2 years ago

607 233 2 years ago

rustpython.github.io

Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.

avgcorrection• 2 years ago

Why does it make you wince?

mavamaarten• 2 years ago

From a non-python dev perspective: I always struggle with dependencies and versions. I have a script in front of me that I want to run, and am often just frustratingly brute-forcing commands to make it work.

Do I:

python? python3? pip install? pip3 install? python pip install? python pip3 install? python3 pip install? python3 pip3 install?

And then everyone mentions "oh just use venv" or "conda" or docker or... It just never ends or it never clearly explains what to do. And all I want to do is run a relatively simple script. Or course I would use a docker image to run a more complex app. But it's frustratingly hard to manage for people who don't use it often.

I'm from a java/Kotlin world where things aren't perfect either. But at least dependencies are clearly defined, and the only thing you need is Gradle that updates itself through a wrapper script if needed and pulls all dependencies. And a JVM/JDK which is also configured/installed quite clearly in a specific location.

postepowanieadm• 2 years ago

Installing python software is hard. Golang is much easier for and end user.

lumb63• 2 years ago

Personally, I wince at Python because, while I view it as a quick-and-dirty scripting language, some people write production code in Python. And here we are ten years later, stuck with code that reads a few metrics from the system, packages them into JSON, and sends them to an API for monitoring. The code takes 7 seconds at 100% CPU to resolve the imports, every time it runs.

berkes2• 2 years ago

I was recently looking for some ways to make a rust project dynamically configurable. Yaml/toml/etc are too static or are terrible to describe logic in (yet we do it all the time for CI, infra etc, ugh).

WASM would be an option, but overengineered for my case. Ruby (through Artichoke), or Python (through RustPython); but they come with the downside of introducing Ruby or Python. I haven't decided yet, but would prefer Lua for it's simplicity. Or JavaScript (a subset) for how easy it can be limited in scope.

Are there any (example) rust programs out there that have embedded scripting, or runtime plugins or addons in a scripting language?

ddorian43• 2 years ago

why not lua?

leoedin• 2 years ago

There's Rhai - https://rhai.rs/

shzhdbi09gv8ioi• 2 years ago

There's a bunch of scripting languages written in rust that targets "embed-in-rust", for example

https://crates.io/crates/rhai

https://crates.io/crates/dyon

https://crates.io/crates/duckscript

You can use the above links to browse crate "dependents", that is other crates using these dependencies if you are looking for example usage.

tveita• 2 years ago

Your requirements are very close to Starklark - an embeddable programming language intended for configuration with an available Rust implementation.

https://docs.rs/crate/starlark/latest

sanxiyn• 2 years ago

You are looking for Starlark. https://github.com/facebookexperimental/starlark-rust

tracker12• 2 years ago

For JavaScript, all the underlying work used for Deno is pretty much done. I'm not sure if a more complete example.

Though Lua probably has lots of good and feature rich examples as well.

Can't speak at all to Ruby or Python integrations.

In the end, I'd suggest it depends on your audience and what existing skills or biases they're likely to bring to the table.

My one warning is that I've used software that integrated JS and it hasn't aged well. From the Adobe products with ExtendScript to other, older and incompatible JS engines before ES5 even, don't get locked into something difficult to update and keep current.

pkolaczk2• 2 years ago

Rune - https://github.com/rune-rs/rune

repelsteeltje3• 2 years ago

Working on a significant C++ code base (shipped as deb, rpm and windows binaries) and wanting to allow some means to customize busyness logic we decided to integrate Python hooks, a couple of years ago. In hindsight, I'd call that decision a mixed blessing.

The code level integration (pybind11) was nice and easy, the issues came later. We found operational problems (multithreading), performance (in particular initialization) and worst: memory leaks and crashes on python VM teardown. Another problem was that python has it's own particular ideas about package management than generally don't rhyme with packages from the OS vendor.

I'm not sure what the angle is in this project, but I don't see a happy ending for projects that rely on both pip and cargo when it comes to maintenance and long-term support except for source-level integration. That is, unless there is some well designed and well thought out strategy to combine Rust and Python worlds that doesn't conflict with the RPM or apt view of doing things.

galangalalgol7• 2 years ago

Rust bindings into the OS packages aren't nearly as common as in C++, so that could be a saving point. With MUSL builds there can easily be no shared dependencies at all, and with glibc builds it would just be glibc and a couple friends.

sneed_chucker• 2 years ago

Curious why your team didn't opt for Lua instead? It's the more typical choice for the use case you're describing.

UncleEntity2• 2 years ago

As a counterpoint, Blender uses python for non-trivial tasks quite successfully. Though...it is quite easy to get blender to crash because python references to C objects become invalidated or whatever.

I've spent tons of time tracking down python crashes from C extensions -- not how a company wants their devs spending their time -- and 99% of the time its just getting the reference counts right so C and python are on the same page. Dependency management of C pointers gets tricky sometimes...

My usual workflow when I'm wrapping a C/C++ library (which I do for 'fun' quite often) is to generate a skeleton of the python module with pybindgen and then hand-tune it until it works. I could write a bunch of custom wrapper code (which I do use when it makes things easier but it gets thrown away after the skeleton is generated so doesn't have to be very robust) and just use the output from pybindgen but that takes a lot more work unless the library falls into pybindgen's happy path. Plus, as I'm doing it for fun, I don't mind spending time to prettify the generated code and add some py-sugar. And the way pybindgen generates docstrings isn't the best so those would have to get handwritten either way.

Admittedly, I just do this kind of stuff as a hobby and industry has different goals so "pinch of salt" and all that.

reedf12• 2 years ago

I think it's very naive for a programming language to make you "wince", tools are tools.

wayvey• 2 years ago

Agree, would like to know more context

blurbleblurble2• 2 years ago

Have you ever used pip?

amelius4• 2 years ago

Python is a great language to Just Get Things Done™.

Rust is great if you like puzzles and want to spend your precious time solving the same memory management riddle over and over again. You do get faster and often more robust code though, although in practice the difference is often not meaningful and the extra time invested doesn't pay off.

IshKebab7• 2 years ago

Tools are tools

Are you trying to say that all tools are the same? There are no bad tools?

Why is it naive for a painful tool to make you wince?

walthamstow• 2 years ago

I've used all kinds of hand tools and cooking utensils that were terrible and made me wince or experience other discomfort as I used them

saltwatercowboy• 2 years ago

That said, python makes me wince.

O lord of the compiler, lend us thine wisdom.

martijnarts• 2 years ago

I think it's really cool that Python has a healthy third-party interpreter community. PyPy, IronPython, Jython, and now RustPython expand Python's accessibility. It's very cool to see how many people are working on this, and I wonder what kind of problems with CPython this has exposed also.

brnt2• 2 years ago

I wonder if anyone actually uses those third-party interpreters for anything serious. I've never come across anyone that did.

gkbrk• 2 years ago

At least PyPy sees real production use.

v3ss0n4• 2 years ago

PyPy is one of the most underrated python implementation. It just makes your pure python code 20x faster without needing to change anything ( if you don't have c++. Extension depends) We had used PyPy in production , especially on Real-time/ asynchronous web apis that doesn't need machine learning stack

networked2• 2 years ago

The release manager for PyPy posted "Ask HN: Is anyone using PyPy for real work?" last year and got many responses: https://news.ycombinator.com/item?id=36940871.

_kbh_• 2 years ago

Ghidra uses Jython not sure if that counts as serious.

copx• 2 years ago

The infamous MMO game EVE uses Stackless Python.. and the players certainly seem to take it very seriously.

pletnes7• 2 years ago

Pypy is nice if you want more performance. From my experience it seems underused. Never seen jython and ironpython used - yet.

timomaxgalvin• 2 years ago

No.. because the only reason to use python is the ecosystem of packages and that's painful enough on the official implementation.

benrutter2• 2 years ago

I think RustPython gets used in ruff (the linter), or at least I saw they were experimenting with that idea. Which is mainly what its built for - running python code in rust, since its still a fair bit slower than cpython.

Otherwise, for normal job running, cloud infrastructure makes this pretty tricky unless you're a big company. I work for a small company and we run python code on things like azure functions, until they support other python interpreters, we'd need a massive expected benefit to justify that sort of self-building of architecture.

dmurray• 2 years ago

We used Jython very extensively at a former employer, a high frequency trading firm. Originally it was to be used as a configuration language, to allow traders to easily write scripts that configured trading strategies written in Java. The scripts grew into a monstrous ecosystem of applications and analytics.

Jython stuck on Python 2 and doesn't have great interop with the rest of the world Python ecosystem, so I wouldn't recommend it for a new project, but it was a big force multiplier in that use case.

haswell3• 2 years ago

It’s been quite a few years since I worked on this, but spent some time implementing and administering an enterprise infrastructure auto-discovery tool (trying to remember the name - it was a very expensive product from HP, who acquired it from Mercury I think) that was built in Java and exposed a scripting layer to admins via Jython.

I haven’t seen much Jython since, but encountered a few enterprise tools doing this. It was an effective way of enabling advanced use cases and extensions of the existing Java stack without requiring the admin/developer to touch Java.

segmondy• 2 years ago

I have seen them used extensively, especially pypy & jython by big companies. I have seen ironpython twice, but I rarely venture into windows/.NET land.

dartos• 2 years ago

I think eve online famously uses a third party interpreter. Stackpython maybe?

emidln• 2 years ago

I've used pypy in anger a few times. I haven't needed to do reasonably performant webdev in python for awhile, but there was a time when PyPy and the cffi-based database drivers could not be beat by CPython interpreters for non-trivial code. This still might be the case, but I haven't profiled it at all (recently). This was back in python 2.7 days in the mid 2010s.

hosteur• 2 years ago

Oh yes! We use pypy for many batch jobs deployed in production.

We switched to pypy several years back and that allowed us to push a great deal more batch jobs through per window with zero code changes.

nprateem• 2 years ago

I tried the latest django with pypy recently and couldn't get it working, which sucked.

WorldMaker• 2 years ago

I wish IronPython ever gets over the Python 3.x hump. It's been "dead" for a while. Every now and then rumors that some developer has started up on it again, but never seems to get to a release state.

To be fair, F# filled most of its niche after it "died" so it's not a need in any way, just a wish for nice things because there were a few years where IronPython was a very nice thing to have.

ZoomerCretin• 2 years ago

IronPython3 seems to be in pretty active development. Unfortunately, there are a lot of features that still need to be added.

curt15• 2 years ago

How do extensions work with interpreters written other languages? Does the interpreter still expose a C API?

ptspts• 2 years ago

PyPy exposes a subset of the CPython C API, which is good enough for many C extensions, and some others can be ported with little effort.

Most other Python implementations don't provide any way to use CPython C extensions.

There is also the HPy API and ABI, which some C extensions target and multiple Python implementations can compile or load.

galangalalgol7• 2 years ago

There is a merge request up to add autogen rust bindings to hpy

https://github.com/hpyproject/hpy/pull/457

wokwokwok• 2 years ago

No.

…and this one is no exception -> https://github.com/RustPython/RustPython/issues/1940

Packages that rely on c dependencies like numpy, etc. only work if you write a custom implementation by hand; the “normal” package flat out doesn’t (and cannot) work.

So basically you get no packages that use native extensions, unless the project explicitly implements support for them.

Pypy is the only implementation I’m aware of that has implemented a c api that is mostly compatible (see https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...)

For eg. Python running in a .net host or a Java host… I think this kind of compatibility would just be flat out impossible.

For rust… hm… probably possible. For wasm? Definitely not.

nickpsecurity• 2 years ago

Would there be a way to write a bridge between the Rust interpreters and C API where calls to existing extension API could work to/from the Rust interpreter?

iAkashPaul• 2 years ago

Wonder how difficult it would be to write something akin to PyO3 but with python syntax for writing rust programs, just like a subset

gary_0• 2 years ago

Does it allow sandboxing, or is Lua still the only good option for that?

There are so many cases where you'd rather not give extension scripts unlimited access to the OS and file system, you'd think this option would be more common...

eptcyka• 2 years ago

Depending on if it supports the various CPython APIs, it'd be non-trivial to sandbox it. On the other hand, if it doesn't expose a CPython API, is it really python?

galangalalgol7• 2 years ago

The CPython API is the main source of overhead in FFI. It is why using numpy to multiply lots of small matricies is so much slower than one large one. This has prompted people to support the simpler and faster HPy API. https://docs.hpyproject.org/en/latest/overview.html

SkiFire13• 2 years ago

Note that Lua is not sandboxed by default. You need to thinker a bit with it or use Luau to actually make it sandboxed.

RantyDave• 2 years ago

Just putting my hand up to say that MicroPython is awesome (and runs on the RP2040). https://micropython.org

antirez2• 2 years ago

I agree. Incredible development environment for a huge number of MCUs. Super fast.

imhoguy• 2 years ago

Being able to run REPL session directly on MCUs and interact with the hardware live with short development loop is such a great idea.

rch• 2 years ago

Your examples in particular have been excellent lately.

westbywest• 2 years ago

At a previous job I was checking out MicroPython due to its support on LEON4 RAD-hardened CPUs like GR740. It was appealing as a possible design path from proof-of-concept implementations with desktop python/numpy (etc) to space-certified platforms, ideally reducing the quantity of code to reimplement in C. https://essr.esa.int/project/micropython-for-leon-pre-qualif...

tracker12• 2 years ago

I'm curious how large the WASM target is.

One of the things that turned me off of C#'s Blazor WASM was the payload size. I've found some of Rust's offerings like yew and leptos more interesting.

c0balt• 2 years ago

It's okay-ish in size, ~10 MB, I made a small playground with an older version a while back: https://playground.cobalt.rocks/interactive

coldtea• 2 years ago

Last blog entry being from "Dec 1, 2021" doesn't make it sound like there's much action.

ergonaught• 2 years ago

The GitHub repo is more relevant for “action”, no?

wraptile• 2 years ago

Last release (0.3.0) was on 2023-09 and last commit was 2 weeks ago

nicce2• 2 years ago

Contribution graph seems pretty good https://github.com/RustPython/RustPython/graphs/contributors

leadingthenet• 2 years ago

Does seem to have died down since June of last year.

youknowone3• 2 years ago

Our team tends to drilling on code more than writing. I know it is not a strategic good way though. Any idea what do you expect to see on the blog?

swyx• 2 years ago

talk about fun technical challenges and "things you wish you had known". endless appetite for that stuff

Twixes• 2 years ago

That's cool, but now for REAL bare-metal performance someone should rewrite Python in an even lower-level language. That's right, Python written in C is gonna be hella fast! Oh, wait…

nicce2• 2 years ago

Rust can be even faster that C on some cases, so not self-explanatory.

Rust compiler can sometimes make better performance optimizations because there are more guarantees that code works as it is supposed to.

You can bypass these with C of course, but you need more manual (and less secure) operations.

tialaramex• 2 years ago

Also as with C++ having a more expressive language means that while you could have done it in C in practice you won't because it sucks to do all this extra labour, whereas in Rust it's fine because the machine did all the hard work.

Monomorphization is an example where that happens, in C if we're sorting and de-duplicating Geese, Customers and BugReports, we're either writing three separate functions dedup_geese, dedup_customers and dedup_bug_reports, or we're using function pointers and we incur the function call overhead when our functions get called. Ouch.

In Rust (or C++) the monomorphization step is going to turn sort & dedup for Geese, Customers and BugReports into separate functions†, and yet we only wrote the code once.

To some extent you can try to mimic this in C via the "X macro" strategy, but now you're not even just writing C any more, you're writing the macros and maybe running them through pre-processing and trying to understand if the result does what you meant, it's a pretty horrible way to work, so again you're discouraged from doing it.

† However the compiler may spot that actually the machine code implementation for say, BugReport and Goose is identical and so it only emits one in the eventual binary with the other just aliased - which may confuse a debugger and thus a human trying to debug it.

galangalalgol7• 2 years ago

Yeah, how crazy is it that a python interpreter written in python is so much faster than the one written in C? My guess is that it is constrained by not breaking the api, where pypy did break it, and that is probably why pypy hasn't gotten more use. That makes me think any python interpreter that fully supports the cpython api will be slow.

syrusakbary• 2 years ago

Happy to see RustPython making awesome progress!

Note: I just realized that they mention wapm in their homepage. We phased out the WAPM CLI in favor of Wasmer (https://wasmer.io), so you can simply run in your shell:

  wasmer run rustpython

Or, if you want to try it using the Wasmer JS SDK:

  import { Wasmer } from "@wasmer/sdk";

  let rustpython = Wasmer.fromRegistry("rustpython");
  let instance = await rustpython.entrypoint.run({
    args: "-c \"print(1)\""
  });
  let output = await instance.wait();

Will send a PR soon it can be updated!

jedahan• 2 years ago

Probably worth a mention this is the creator of wasmer, for anyone interested. (I was curious who 'We' was to see what companies have experience with multiple wasm runtimes and their learnings)

rrr_oh_man• 2 years ago

For a dum dum like me who only dabbles in programming:

What would be a use case for this?

benrutter2• 2 years ago

A big use case is Rust's web assembly support. There are lots of people who'd probably want to run python in the browser, but doing that at the moment is a little shaky. RustPython is maybe a good route for doing this (they give this in "reasons to use" but I can't say I've tried it)

sylware• 2 years ago

python is already written in plain and simple C, it is sad to make it depends on such complex language which is rust (no less worse than c++).

Actually, I would not mind a python interpreter in rv64 assembly (near 0 SDK) instead.

jjtheblunt4• 2 years ago

RustPython is in a development phase and should not be used in production or a fault intolerant setting. Our current build supports only about half of the Python standard library.

Hamuko2• 2 years ago

RustPython can be embedded into Rust programs to use Python as a scripting language for your application

How big are my binaries going to be if I embed a whole Python interpreter in it?

jffry• 2 years ago

Hello world in pure Rust: 400832 bytes

Hello world w/ rustpython interpreting Python[1]: 15459264 bytes

(Rust 1.75.0; rustpython 0.3.0; MacOS / Apple Silicon)

[1] https://github.com/RustPython/RustPython/blob/main/examples/...

Hamuko2• 2 years ago

Huh, that seems extremely reasonable even if it's not a finished product yet.

DanielHB5• 2 years ago

"it can be compiled to WebAssembly in order to run Python in the browser."

I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it.

This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happening (once by the wasm runtime to compile the rust-python wasm and again by the rust-python code compiling your python code). And this is on top of normal performance degradation from using a dynamically typed language compared to a statically typed language

To make dynamic languages (even JS) viable to run in a wasm runtime, the language must be compiled directly to wasm.

Project still looks pretty cool and useful though, there is plenty of python code that could be useful to use in the browser no matter how badly it runs. Just don't try to build a web framework on top of this kind of approach.

Edit: Let me reframe this a bit, this is what I think, I haven't really benchmarked anything and rust python might be doing some tricks I am not aware of.

esrauch2• 2 years ago

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it.

So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard way special cases" byzantine business code to something that can run on a web server and be accessed by the companies employees rather than passing around scripts for them to run, with a lot of benefits including instant upgrades for everyone for bug fixes.

That said, this specific impl claims to only support half of the standard library so I kinda doubt its ready for any 'serious' business usecases yet anyway.

DanielHB5• 2 years ago

I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application. Large python codebases could take like a minute to start if loaded that way.

Once it does start then your arguments can make sense, but even so it would still make it impractical for most things.

Trust me, when the Javascript dev tells you something will be slow, it WILL be very slow

phkahler• 2 years ago

> The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it.

Which means this whole thing is pointless from an end user point of view. The technology stack is getting very deep - Python, Rust interpreter, WASM, in a browser. I'd love to get back to running things on a toaster with no dependencies.

jug• 2 years ago

Sounds like a use case for simple Python rather than RustPython?

If you go full RustPython, surely looking to eek out performance must be a major reason to even go there rather than just script with CPython like it was 1999?

_gabe_• 2 years ago

can move existing "learned the hard way special cases" byzantine business code to something that can run on a web server and be accessed by the companies employees rather than passing around scripts for them to run

Or… you could just use Django. The framework built for running python on a web server.

IshKebab7• 2 years ago

essentially no performance requirements

In my experience this is very rarely actually true, even though people think it is.

zitterbewegung• 2 years ago

You are right for the most part. I attended a talk about pyscript[1] (runs python in the browser using wasm which is similar) and there is a 2x performance hit.

[1] https://pyscript.net

fpliger• 2 years ago

PyScript has actually been massively refactored in the last few months and is much faster now. You can check the performance of PyScript running MicroPython here: https://laffra.github.io/ltk/

If you need/choose Pyodide load time will of course by much more but that's mostly because of the size of full core Python and the dependencies you might have.

hobofan2• 2 years ago

once by the wasm runtime to compile the rust-python wasm

I'm not sure what you mean by that. The runtime doesn't compile WASM, it simply executes it.

There are tools for dealing with interpreter runtime overhead this by pre-initalizing the environment like Wizer[0]. ComponentizeJS[1] uses it to pre-initialize the Spidermoney engine it packages to gain fast startup times (and you can then prune the initialization only code with wasm-opt). As techniques like ComponentizeJS are also being applied for a specific set of interpreted files, you can even prune parts of the interpreter that would never be used for that specific program. If you want to go even further you could record specific execution profiles and optimize based on those.

[0] https://github.com/bytecodealliance/wizer

[1] https://github.com/bytecodealliance/ComponentizeJS

crabmusket• 2 years ago

The runtime doesn't compile WASM, it simply executes it.

That's not necessarily true. For example, Wasmtime uses Cranelift to compile WASM binary into native code. https://docs.wasmtime.dev/contributing-architecture.html

bhelx• 2 years ago

I can't speak for rustpython, but you can partially evaluate dynamic languages in wasm with something like wizer https://github.com/bytecodealliance/wizer. So you can let the runtime do all the parsing and compiling ahead of time. We do this with javascript (quickjs). It does have a few downsides regarding memory size but it is pretty fast.

habitue• 2 years ago

Ok wow, wizer is really really cool. I was thinking a few months back it would be great if you could dump out the jitted version of a wasm program so you could load it faster and... here it is, someone has built it.

That's wonderful.

Next up, wasm supercompiler...

DanielHB5• 2 years ago

Yeah this is really interesting, could make this kind of approach viable.

Izkata• 2 years ago

> "it can be compiled to WebAssembly in order to run [..] in the browser."
and NodeJS

Wait... what? Why?

DanielHB5• 2 years ago

So you can run NodeJS code in the browser, even though both are JS-based, NodeJS has a bunch of APIs that deal with things like file systems that the browser doesn't have.

For example, imagine you have a lib that converts markdown to html, but the lib happens to write the files directly to the disk, hence it can't be used in the browser. If you compile the nodejs runtime to wasm with a WASI that maps the file system to local storage, then you can just read the file from local storage after invoking the lib.

Just saying it is a technical possibility, this kind of approach is really only meant to be used if you _really_ just want to run some lib in the browser, no matter how slow it gets.

Also technically if you could compile JS to wasm (without nodejs, so more like how you run C through wasm right now) then you don't need to care about browser versions and JS api polyfills while still using JS.

paulddraper2• 2 years ago

And this is on top of normal performance degradation from using a dynamically typed language

You already counted that, that's the Python interpreter (in this case RustPython) overhead.

---

The steps are (1) RustPython interpreter (2) Rust compiled to WASM (3) WASM runtime.

"Normally" you'd have (1) CPython interpreter (2) C compiled to machine code.

I'm not sure how much overhead WASM runtime really is...I'm curious, but I doubt this is awful compared to CPython.

---

FYI, for CPython as WASM, https://pyodide.org/.

_pdp_• 2 years ago

RustyPython is more memorable and has a catchy flair; my $0.02

xpe• 2 years ago

Rust y Python is what a Spanish speaker calls a project that uses both (:

greenie_beans• 2 years ago

RustyPy

amelius4• 2 years ago

Cool. Can I use NumPy, SciPy, PyTorch, Shapely, ...?

sakesun2• 2 years ago

I thought RustPython is what Ironpython become after being abandoned for a while.

Induane• 2 years ago

I feel smart because I got your very funny joke.

Silliness aside, I actually had almost the same thought when I was reading the post lol. Great minds think for themselves so I guess maybe we're only really good minds then. Ahh well....

paulddraper2• 2 years ago

Ha ha.

For those interested, Iron* is .NET.

IronPython

IronRuby

IronJS

estebank• 2 years ago

Just wait until we get IronRust through a clr rustc backend :)

antod2• 2 years ago

I thought it was renamed after Oxide picked up the sponsorship.

sakesun2• 2 years ago

So many people upvote this comments that I feel like I'm Xavier.

sbt567• 2 years ago

I've been using RustPython for my side project (scripting purpose) and its been amazing ride so far! (albeit with minimal docs which is understandable at this stage). AFAIK, the parser also been used in the awesome ruff project

sebastianconcpt• 2 years ago

How is it about safety then? All the Rust program parts scripted using python are unsafe?

thurn• 2 years ago

How does their garbage collection work? Especially in Rust it would be cool to see a concurrent collector.

posix_monad2• 2 years ago

I'm not convinced that projects like this can really have broad application. The value of Python is interfacing to native libraries, but as soon as you use something like PyPy, you lose access to all of that. It's the same story with the performance orientated forks of cPython.

ixaxaar• 2 years ago

Pretty much. Ecosystem brings most of the value than any programming language.

posix_monad2• 2 years ago

It's particular acute with Python. The language itself is poor - the value is in the massive ecosystem (particularly around ML).

Compare this to say, Rust, where the safety guarantees are useful in their own right.

There would be value in Rust even with zero packages, but I couldn't say the same for Python.

hobofan2• 2 years ago

As some popular libraries begin being authored in Rust (e.g. Polars), I'm wondering whether that could actually be exploited in this approach, by e.g. shipping the "native" libraries as WASM components that can then be called instead of the actual native libraries.

ildjarn2• 2 years ago

Given how the Python community has failed to converge on a good set of packaging and bundling tools that I highly doubt this will happen.

Perhaps this kind of thing needs to be baked into a language offering from the start?

stratigos• 2 years ago

please, just stop with Python already

ReflectedImage• 2 years ago

We can't do that as Python is the programming language that meets business needs the best and they pay the bills.

qwerty456127• 2 years ago

Each of these implementations offer some benefits: Jython, for example, compiles Python 2 source code to Java byte code... IronPython is well-integrated with .NET, which means IronPython can use the .NET framework and Python 2 libraries or vice versa.

Python 2 is dead and that's why Jython and IronPython, who have failed to catch up with Python 3, are dead as well and are not worth mentioning, are they?

lastmjs• 2 years ago

We've been using RustPython as the Python interpreter for our project Kybra, which is a Python environment for the Internet Computer Protocol (decentralized cloud, where all programs are automatically replicated across 13-40 nodes). Wasm is the runtime environment on ICP.

It's been working quite well, though lack of C extensions is a problem. We're hoping to move to CPython once the wasi and C extension support is there.

But the project works, compiles to wasm32-wasi, and can execute on the live ICP network: https://github.com/demergent-labs/kybra

willquack• 2 years ago

What has your experience been with Pyodide? Why did you opt for RustPython instead?

youknowone3• 2 years ago

Thank you for working with RustPython. I believe kybra made RustPython wasi support a lot more stable.

dang• 2 years ago

RustPython – A Python-3 (CPython >= 3.11.0) Interpreter written in Rust - https://news.ycombinator.com/item?id=35056586 - March 2023 (136 comments)

A full Python interpreter written in Rust - https://news.ycombinator.com/item?id=31086317 - April 2022 (7 comments)

Python interpreter written in rust reaches 10000 commits - https://news.ycombinator.com/item?id=29094323 - Nov 2021 (93 comments)

RustPython: A Python interpreter written in Rust - https://news.ycombinator.com/item?id=28280790 - Aug 2021 (49 comments)

RustPython – Python Written in Rust - https://news.ycombinator.com/item?id=27060802 - May 2021 (2 comments)

A Python interpreter rewritten in Rust, that can run pip - https://news.ycombinator.com/item?id=26030269 - Feb 2021 (48 comments)

A Python Interpreter Written in Rust - https://news.ycombinator.com/item?id=19064069 - Feb 2019 (194 comments)

janalsncm2• 2 years ago

I’ve been going the other way, adding rust bindings for some performance-critical code, and calling it from Python. It’s worked wonders, speeding things up 20-30x in some places. This also has the benefit of compiling to WASM if I need to, so it’s a breeze to run my code in the browser.

dathinab• 2 years ago

not sure if you use pyo3 but it works wonders

(except for some minor parts as well as the python in rust cross compilation case (last I tried ~1y ago), the rust in python cross compilation is fine tho)

janalsncm2• 2 years ago

Yeah pyo3. It also plays nicely with rust’s numpy so for a lot of deep learning applications you can load a file in rust and build your data, then pass it to python ML libraries.

Only issue I’ve had so far are some weird issues with conda versions and maturin. But those were basically my fault.

ashish012• 2 years ago

I was curious about how slow (or fast) it is compared to cpython. On fibonacci.py rustpython about 11x slower than cpython.

    def fib(n):
        if n == 0 or n == 1:
            return 1
        return fib(n-1) + fib(n-2)

    print(fib(35))

    time python3 ~/code/fibs.py
    14930352

    ________________________________________________________
    Executed in    1.18 secs    fish           external
       usr time    1.14 secs  180.00 micros    1.14 secs
       sys time    0.01 secs  616.00 micros    0.01 secs

    time ./target/release/rustpython ~/code/fibs.py
    14930352

    ________________________________________________________
    Executed in   13.44 secs    fish           external
       usr time   13.32 secs  175.00 micros   13.32 secs
       sys time    0.02 secs  776.00 micros    0.02 secs

soerxpso• 2 years ago

Using the .__jit__() method in your rustpython version might get you a speedup (I assume they intend for this to be automatic eventually, and it's only explicit right now while the feature is under construction).

ashish012• 2 years ago

I tried jit as well but looks like recursive functions cannot be jitted yet :(

RustPython

Related Stories