I wonder whether <https://github.com/rust-lang/rus...
# development
I wonder whether https://github.com/rust-lang/rust/pull/58057/ will do anything for us... I'm guessing not particularly...
more inlining across generated C code + whatever python headers we pull in sounds like a potential perf opportunity but i don't know exactly what kind of code cffi/libffi uses to glue things together so not sure if that will matter
the C portion of cffi is relatively thin
but if we were to directly embed the python interpreter via https://github.com/pantsbuild/pants/issues/7369 ...
if we were to embed the python interpreter by building from source and/or using LTO that could at the very least remove any perf concerns about calls across ffi boundaries
There would still be perf concerns around e.g. the GIL. But yeah, an interesting corner…
there are a lot of potentials in these areas... i've played with https://github.com/PyO3/pyo3, and it seemed quite solid. with the (very significant) downside that it requires nightly
https://github.com/RustPython/RustPython is also a thing, although still with a GIL, and probably ages from being able to run
(wonder whether anyone has tried...)
and then, there's always starlark.
(oh, um... i think pyO3 removed support for python2 in the weeks since i last looked at it... probably for the best)
also not sure whether it supports static linking.
i would love to use starlark wherever it benefits us which it seems like could be a lot of places
i would also like to implement the bazel build api so we can consume bazel rules either through a specific FFI (from python to starlark) or 1:1 with v2 rules