Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RustPython

rustpython.github.io

Post reply on HN
Print view View original

121–130 of 244 posts

Re: RustPython

#121

Post by emidln »

brnt wrote: post #4
martijnarts wrote: post #3

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.

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

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.

Re: RustPython

#122

Post by hosteur »

brnt wrote: post #4
martijnarts wrote: post #3

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.

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

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.

Re: RustPython

#123

Post by simonw »

DanielHB wrote: post #105
esrauch wrote: post #97

Earlier quoted context omitted.

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…

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 slo…

Pyodide (standard cPython in WebAssembly) loads surprisingly quickly.

My https://lite.datasette.io application usually starts up in less than 10s - most of that is downloading about 10MB of WASM blobs, and 10MB isn't actually that big these days (many sites serve more than that in image headers).

When I built Datasette Lite I did it as a research project, assuming it would be far too slow loading to be useful. I've since changed my mind on that.

Re: RustPython

#124

Post by repelsteeltje »

pipo234 wrote: post #118
galangalalgol wrote: post #34

Earlier quoted context omitted.

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.

Yes, C++ definitely tends to rely more on binary dependencies, shared objects. Rust will probably have to as well, once frameworks and libraries get to size and maturity that you want your OS vendor to take over responsibility (and compile time!). And note that even MUSL doesn't help create a package that works seamlessly on any Linux OS/release — maybe WASM will (or more accurately: WASI). But I think, the point GP…

> Preferably do it following the existing packages and lore of that distro, rather some python and some rustup version?

Exactly! I want customers to be able to install my software on stock Ubuntu 24 / Rocky 9 / .. and seamlessly integrate with existing stock Apache, libcurl, libssl without any recompilation etc.

Having a bunch of pip dependencies tag along makes this quite complicated.

Re: RustPython

#125

Post by ptx »

mavamaarten wrote: post #36
avgcorrection wrote: post #7

Earlier quoted context omitted.

Why does it make you wince?

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 ju…

Part of the problem is that this used to require third-party tools, which gave rise to lots of different tools, but nowadays everything you need is included in Python itself.

The simplest way (in the sense of having the fewest components required) is this, using only built-in tools:

  $ python3 -m venv --upgrade-deps my-virtual-environment
  $ my-virtual-environment/bin/pip install whatever-third-party-package
  $ my-virtual-environment/bin/python3 my-script.py
This creates an isolated virtual environment in "my-virtual-environment". Use the pip and python3 binaries inside that directory to install packages and run scripts. Done. (The "activate" step suggested in other comments is just a convenience for setting your PATH to refer to the virtual environment implicitly, so that's completely optional.)

Note that Debian's python3 package leaves out some parts of the standard Python distribution, but you can install the python3-full package for a complete installation.

Re: RustPython

#126

Post by rch »

antirez wrote: post #109
RantyDave wrote: post #28

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

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

Your examples in particular have been excellent lately.

Re: RustPython

#127

Post by lumb63 »

avgcorrection wrote: post #7
blurbleblurble wrote: post #2

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

Why does it make you wince?

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.

Re: RustPython

#128

Post by hobofan »

DanielHB wrote: post #89

> "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 happeni…

> 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

Re: RustPython

#130

Post by [deleted] »

DanielHB wrote: post #105
esrauch wrote: post #97

Earlier quoted context omitted.

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…

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 slo…

[deleted]
Post reply on HN