PyO3 is a clever name
I don't get it. What's the pun?
Calling Rust from Python using PyO3
11–20 of 51 posts
Re: Calling Rust from Python using PyO3
#12Re: Calling Rust from Python using PyO3
#13This is smart thinking. Python is the world's best glue language and Rust is on track to become the world's best compiled, safe language. It makes sense to combine the two and replace C in this.
For compiled languages: Rust is the best when you care about memory safety. C is the best when you care about performance/simplicity/portability. C++ is the best when you care about modularity, Assembly is the best when you care about lowlevel stuffs, ...
For interpreted languages: Python is the best for data science, Java is the best for entreprise, Javascript is the best for speed, ...
Each one have a use case where they are the best. And those use cases I listed above, are entirely subjectives and will never be the same from person to person.
If there was an objectively best language period, why would other languages exist?
Re: Calling Rust from Python using PyO3
#14This is smart thinking. Python is the world's best glue language and Rust is on track to become the world's best compiled, safe language. It makes sense to combine the two and replace C in this.
While Python's bindings in other languages are great, and Rust has amazing features regarding memory safety, I think saying they are the best in their area is a bit too much. For compiled languages: Rust is the best when you care about memory safety. C is the best when you care about performance/simplicity/portability. C++ is the best when you care about modularity, Assembly is the best when you care about lowlevel s…
Re: Calling Rust from Python using PyO3
#15I hope someone creates a rule set for Bazel to automate this stuff. This seems like a really nice way to start rewriting performance critical code in a safe language!
I’ve been having difficulty recently trying to get bazel and rust to work together nicely. It seems like cargo does a lot of heavy lifting w.r.t. dependencies which Bazel does not like. Do you have to vendor your dependencies- and your dependencies dependencies. Ad infinitum. There is cargo-raze which helps, but only if you’re making a rust library: not if you’re making a binary. So maybe it works for this case.
I'm really hoping bzlmod helps in this case: https://www.youtube.com/watch?v=TxOCKtU39Fs
The story for external deps is indeed extremely painful right now.
Re: Calling Rust from Python using PyO3
#16Earlier quoted context omitted.
While Python's bindings in other languages are great, and Rust has amazing features regarding memory safety, I think saying they are the best in their area is a bit too much. For compiled languages: Rust is the best when you care about memory safety. C is the best when you care about performance/simplicity/portability. C++ is the best when you care about modularity, Assembly is the best when you care about lowlevel s…
C, C++, and Assembly aren't safe, and Java and JS aren't good glue languages.
My point was that if you don't care about safety, C/C++/ASM have good aspects too.
I can write a program without a single pointer in C, and it will be fast, small, and portable.
Java is used a lot in data science alongside Python. And Javascript also have bindings for Tensorflow and other libs. They are scripting languages able to call C code, by definition they are glue languages.
Re: Calling Rust from Python using PyO3
#17I hope someone creates a rule set for Bazel to automate this stuff. This seems like a really nice way to start rewriting performance critical code in a safe language!
I’ve been having difficulty recently trying to get bazel and rust to work together nicely. It seems like cargo does a lot of heavy lifting w.r.t. dependencies which Bazel does not like. Do you have to vendor your dependencies- and your dependencies dependencies. Ad infinitum. There is cargo-raze which helps, but only if you’re making a rust library: not if you’re making a binary. So maybe it works for this case.
Re: Calling Rust from Python using PyO3
#18This is smart thinking. Python is the world's best glue language and Rust is on track to become the world's best compiled, safe language. It makes sense to combine the two and replace C in this.
While Python's bindings in other languages are great, and Rust has amazing features regarding memory safety, I think saying they are the best in their area is a bit too much. For compiled languages: Rust is the best when you care about memory safety. C is the best when you care about performance/simplicity/portability. C++ is the best when you care about modularity, Assembly is the best when you care about lowlevel s…
Python is currently the easiest language to learn, has a plethoa of modules in it's standard library alone, plus a vast ocean of 3rd party libraries. From displaying cute cats inside your terminal, to large mathematical monoliths like numpy and scipy. Python has almost everything you need to build programs, minus the speed and easy distribution of executables.
Java is semi-compiled and too verbose to be a glue language.
Javascript is faster than Python, but is much more difficult to use efficiently. It's standard library is such a joke that I had to install a 3rd-party library just to use a input() equivalent.
Re: Calling Rust from Python using PyO3
#19Re: Calling Rust from Python using PyO3
#20Earlier quoted context omitted.
C, C++, and Assembly aren't safe, and Java and JS aren't good glue languages.
So? My point was that if you don't care about safety, C/C++/ASM have good aspects too. I can write a program without a single pointer in C, and it will be fast, small, and portable. Java is used a lot in data science alongside Python. And Javascript also have bindings for Tensorflow and other libs. They are scripting languages able to call C code, by definition they are glue languages.
Wheelerof5te said Rust is becoming the "world's best *compiled, safe* language". You objected to this, but then only listed alternative languages which aren't in that group. You responded as if Wheelerof5te had claimed there was "an objectively best language period".
> They are scripting languages able to call C code, by definition they are glue languages.
If I say something like "world's best chef" then I mean the person who is best at being a chef. Not the world's best (most moral?) person who happens to also fulfill the definition of being a chef but may be pretty bad at cooking. I think the same was intended here for "best glue language" - best at being a glue language.