Hacker News Reader

Comment by wongarsu | Hacker News Reader

It's worth mentioning that Rust-Python interoperability is already great, in both directions, thanks to pyo3

Seconding this. I learned a little rust and really liked its philosophy. I was then working on a small project that needed to avoid the big data science python libraries because they're miserable in terms of portability to air-gapped networks.

We had re-implemented a few mathematical and curve finding functions and even with the newest python they were uncomfortably slow.

PyO3 made it so easy to implement a runtime switchable rust library exposed to python, it was almost unnerving. By writing those handful of functions in rust we got something like a 30x speedup.

Note this was a small project with limited funding for r&d so the level of effort for performance speedup was really nice.

Why not compile those (python scientific) libraries from source? Why would PyO3 be acceptable while e.g. numpy is not?

needing to compile them on the airgapped machine introduces more dependencies. Things also get weird when your airgapped machine is a slight version off from your dev machine. There's a lot of ways around it but we've found for the size of this tool, it was preferable to just write our own handful of math functions over building out a deployment method for extra dependencies.

Yeah, PyO3 is great. I've tried to play around with releasing the GIL from rust in Python 3.12. I would enjoy writing a WSGI/ASGI server with a Celery runtime at some point too. Or contribute to Granian.

https://github.com/emmett-framework/granian

PyO3 is great. But it needs more and better documentation.

I recently did use it for a project, and it was quite a lot of time and pain guessing what would work and what wouldn't.

Reply on news.ycombinator.com