Hello from Pantsbuild! (Mentioned above by @davidhewitt, PyO3’s author above)
I couldn’t tell how community feedback was expected to be collected, so I’ll put my little blurb here.
Our project uses a Rust engine leveraging tokio’s async event loop and wiring that up to Python’s. The engine itself is implemented as an extension module, and the application is a Python app. The only reason we use Python anymore is because it’s a VERY great language for rapid development and readability. We just couldn’t expect our wonderful plugin authors to write everything in Rust.
At the boundary, we’re consuming read-only deep Python data structures. We leverage PyO3 to make that simple. (An interpreter pool could work if those could read shared memory AND PyO3 consumed it, but still not ideal)
Python was also the first language supported in our build system in V2, and I’d argue we have best-in-class monorepo support for Python. So, we <3 Python.
The GIL is one of the reasons we see poor multi-core performance in a lot of scenarios. When we measure those we port them to Rust. Not because Rust is fast but because we can do work outside of the GIL.
I can likely make a very strong case for porting the Rust code back to Python if the GIL wasn’t holding us back. Having the code be pure-Python means it’s easier to read for everyone, and we don’t split ourselves between Rust and .pyi to get good type support. And faster development.
Lastly, our use case doesn’t rely on 3rdparty libraries (we do today, but those can easily be removed). So we’d immediately benefit from a no-gil CPython (once PyO3 support was merged). I actually tried it out, but hit a few bugs/snags. I’m eager to try it again.
So, there’s our data point 