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

111–120 of 244 posts

Re: RustPython

#111

Post by networked »

froh wrote: post #93
dmurray wrote: post #75

Earlier quoted context omitted.

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

there are JEP, JPype and PyJNIus these days...

Those are bridges to native CPython. There is also GraalPy (https://github.com/oracle/graalpython), which is a standalone implementation more similar to Jython. It seems already quite compatible with Python 3.

I have tested the latest version graalpy-community-23.1.2 as a regular Python interpreter from the command line (i.e., not through a Java program). It was able to run my standard library-only Python scripts, as well as a script that made async HTTP requests with the external library HTTPX. It couldn't run a TUI program that used the Python Prompt Toolkit (`AttributeError: module 'signal' has no attribute 'siginterrupt'`).

I am curious about your experience if you have used GraalPy more than I have.

Re: RustPython

#112

Post by _gabe_ »

esrauch wrote: post #97
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…

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…

> 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.

Re: RustPython

#113

Post by doix »

virgildotcodes wrote: post #84
haswell wrote: post #79

Earlier quoted context omitted.

Python has been my go-to for prototyping since 2003. Maybe I’ve just adjusted to its quirks, but I keep returning to it despite picking up another dozen languages since. I’ve encountered other people who hate it, but never understood why; what issues are you experiencing?

I honestly don’t think I’ve ever been able to git clone any python project (that isn’t hello world equivalent), follow the readme and have it just run first shot. I’m always having to dive in and figure out which packages are missing, wrong version, etc. As I do this I find myself wondering if the repo maintainers make a habit of actually trying to set up their project from scratch just by following their readmes. I’…

Do you have any examples? I've been out of the Python game for _ages_, but can't you pretty much always just:

  git clone ...
  python -m venv venv
  source ./venv/bin/activate
  pip install -r requirements.txt
Then work on that repo? Everything after "venv" is too new for me, and I've ignored it and somehow not had any issues. If there are some packages that rely on C code and don't have wheels or whatever, you need to deal with the C ecosystem which is the real hell in my opinion.

All the autotools/cmake/scons, library paths, header paths, PKG_CONFIG, etc. I've had so many issues building C projects that I can't even begin to remember all the issues.

Re: RustPython

#116

Post by aldanor »

fluidcruft wrote: post #110
aldanor wrote: post #47

Earlier quoted context omitted.

Sometimes, Things just can't be Done with Python. E.g., you're parsing dozens terabytes of data, or need response time within a microsecond. So, you're left with a choice of C++, Rust (what else, C#, possibly Zig and a few other). Rust stops being a "puzzle" once you've written enough of it and you just know how to do things. It has one major disadvantage though - returning back to write in languages like C++/Python…

I really, really get interested in rust sometimes and then I read comments like yours and remember the warnings about premature optimization and put it off again.

Well, it shouldn't be a surprise to anyone that there's many use cases out there where you just have no other choice but to use a lower-level language (where, unfortunately or not, the common tool of choice these days is still C/C++) since the application/library is either dealing with too much data or has to be very responsive, or both. Since this thread is about Python, some good well-known examples would be libraries like numpy/pandas; but there's also some like polars that are written in Rust.

Re: your point, I'd still recommend learning Rust even if it's just solving last year's AoC, to see how various data structures, enums, traits, iterators etc work. Even if you don't end up using Rust on daily basis, it will probably affect the way you structure non-Rust code and provide you with a few neat design ideas.

Re: RustPython

#117

Post by sbt567 »

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

Re: RustPython

#118

Post by pipo234 »

galangalalgol wrote: post #34
repelsteeltje wrote: post #9

Earlier quoted context omitted.

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

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 is making is more about the dependencies Python ads to your C++ (or Rust). Ie.: build RustPython project to produce artifact that works on my machine, but relies on my python interpreter, my (which may have C dependencies) as well as a rust edition and cargo. How can I bundle this into a package for a different Linux? Preferably do it following the existing packages and lore of that distro, rather some python and some rustup version?

Re: RustPython

#119

Post by ctippett »

FergusArgyll wrote: post #46
mavamaarten wrote: post #36

Earlier quoted context omitted.

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…

for simple scripts, this is the easiest and works. python3 -m venv venv source venv/bin/activate pip install whatever echo "source path/to/venv/bin/activate && python3 path/to/app.py" > myscript mv myscript /usr/local/bin and just use myscript. I use this for a lot of little scripts

I haven't tried this myself, but you could probably save yourself the wrapper script and execute your script directly by adding a shebang pointing to the Python executable from your virtual environment.

printf '%s\n%s\n' "#!path/to/venv/bin/python3" "$(cat path/to/app.py)" > /usr/local/bin/myscript

Re: RustPython

#120

Post by imhoguy »

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.

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