However I think there are some assumptions made on the part of the author I’m not sure I agree with.
If you’re a Python developer, choosing to introduce Cython to speed up your code means the addition of some type annotations and maybe a few code changes.
To introduce Rust (awesome though it is!) into the equation means investing a rather non trivial amount of time into learning that language and ecosystem.
At work, we wrote a static type checker for Python with a gradual and sound type system, added primitive (unboxed) types, and flowed the types through to the JIT. The generated code ends up being faster than Cython code for most (really like 99%) use-cases because there are no more FFI boundaries.
This is called Static Python, which is part of Cinder. I gave a talk (PDF) at ECOOP 2022 that shows off Static Python a bit (among other things).
#5 is not a problem. Or, rather, the way it’s phrased is misleading. #5 isn’t about Python-only code; after all, Cython is not Python, so by definition, a solution with Cython cannot be Python-only.
Similarly, Rust doesn’t solve #5, since code must be written in Rust. It also doesn’t solve #2, because the Rust compiler does not emit Python source code or CPython bytecode.
I say all of this because the obvious solution to all five criteria isn’t mentioned; if you want pure Python code to go faster, check out PyPy.
When I first met Cython (while looking for options on how to do bindings) I was surprised. It seemed like a really interesting programming language and almost nobody was using it. However, I did not know about some of these problems, and now it makes more sense to me.
Great article!
However I think there are some assumptions made on the part of the author I’m not sure I agree with.
If you’re a Python developer, choosing to introduce Cython to speed up your code means the addition of some type annotations and maybe a few code changes.
To introduce Rust (awesome though it is!) into the equation means investing a rather non trivial amount of time into learning that language and ecosystem.
I tried to make that tradeoff clear, but possibly I could’ve been more explicit.
At work, we wrote a static type checker for Python with a gradual and sound type system, added primitive (unboxed) types, and flowed the types through to the JIT. The generated code ends up being faster than Cython code for most (really like 99%) use-cases because there are no more FFI boundaries.
This is called Static Python, which is part of Cinder. I gave a talk (PDF) at ECOOP 2022 that shows off Static Python a bit (among other things).
Really cool work on Cinder, thanks for the presentation link!
Let me know what questions you have :)
#5 is not a problem. Or, rather, the way it’s phrased is misleading. #5 isn’t about Python-only code; after all, Cython is not Python, so by definition, a solution with Cython cannot be Python-only.
Similarly, Rust doesn’t solve #5, since code must be written in Rust. It also doesn’t solve #2, because the Rust compiler does not emit Python source code or CPython bytecode.
I say all of this because the obvious solution to all five criteria isn’t mentioned; if you want pure Python code to go faster, check out PyPy.
When I first met Cython (while looking for options on how to do bindings) I was surprised. It seemed like a really interesting programming language and almost nobody was using it. However, I did not know about some of these problems, and now it makes more sense to me.
Lots of people use it! E.g. 5% of Pandas codebase. Pandas had 100M downloads last month :)