91–100 of 244 posts
> RustPython can be embedded into Rust programs to use Python as a scripting language for your application How big are my binaries going to be if I embed a whole Python interpreter in it?
Hello world w/ rustpython interpreting Python[1]: 15459264 bytes
(Rust 1.75.0; rustpython 0.3.0; MacOS / Apple Silicon)
[1] https://github.com/RustPython/RustPython/blob/main/examples/...
I think it's really cool that Python has a healthy third-party interpreter community. PyPy, IronPython, Jython, and now RustPython expand Python's accessibility. It's very cool to see how many people are working on this, and I wonder what kind of problems with CPython this has exposed also.
Earlier quoted context omitted.
I wonder if anyone actually uses those third-party interpreters for anything serious. I've never come across anyone that did.
We used Jython very extensively at a former employer, a high frequency trading firm. Originally it was to be used as a configuration language, to allow traders to easily write scripts that configured trading strategies written in Java. The scripts grew into a monstrous ecosystem of applications and analytics. Jython stuck on Python 2 and doesn't have great interop with the rest of the world Python ecosystem, so I wou…
That's cool, but now for REAL bare-metal performance someone should rewrite Python in an even lower-level language. That's right, Python written in C is gonna be hella fast! Oh, wait…
Rust can be even faster that C on some cases, so not self-explanatory. Rust compiler can sometimes make better performance optimizations because there are more guarantees that code works as it is supposed to. You can bypass these with C of course, but you need more manual (and less secure) operations.
Monomorphization is an example where that happens, in C if we're sorting and de-duplicating Geese, Customers and BugReports, we're either writing three separate functions dedup_geese, dedup_customers and dedup_bug_reports, or we're using function pointers and we incur the function call overhead when our functions get called. Ouch.
In Rust (or C++) the monomorphization step is going to turn sort & dedup for Geese, Customers and BugReports into separate functions†, and yet we only wrote the code once.
To some extent you can try to mimic this in C via the "X macro" strategy, but now you're not even just writing C any more, you're writing the macros and maybe running them through pre-processing and trying to understand if the result does what you meant, it's a pretty horrible way to work, so again you're discouraged from doing it.
† However the compiler may spot that actually the machine code implementation for say, BugReport and Goose is identical and so it only emits one in the eventual binary with the other just aliased - which may confuse a debugger and thus a human trying to debug it.
Earlier quoted context omitted.
No.. because the only reason to use python is the ecosystem of packages and that's painful enough on the official implementation.
Python has been my go-to for prototyping since 2003. Maybe I’ve just adjusted to its quirks, but I keep returning to it despite picking up another dozen languages since. I’ve encountered other people who hate it, but never understood why; what issues are you experiencing?
Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.
I was recently looking for some ways to make a rust project dynamically configurable. Yaml/toml/etc are too static or are terrible to describe logic in (yet we do it all the time for CI, infra etc, ugh). WASM would be an option, but overengineered for my case. Ruby (through Artichoke), or Python (through RustPython); but they come with the downside of introducing Ruby or Python. I haven't decided yet, but would prefe…
> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…
So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard way special cases" byzantine business code to something that can run on a web server and be accessed by the companies employees rather than passing around scripts for them to run, with a lot of benefits including instant upgrades for everyone for bug fixes.
That said, this specific impl claims to only support half of the standard library so I kinda doubt its ready for any 'serious' business usecases yet anyway.
> RustPython can be embedded into Rust programs to use Python as a scripting language for your application How big are my binaries going to be if I embed a whole Python interpreter in it?
Hello world in pure Rust: 400832 bytes Hello world w/ rustpython interpreting Python[1]: 15459264 bytes (Rust 1.75.0; rustpython 0.3.0; MacOS / Apple Silicon) [1] https://github.com/RustPython/RustPython/blob/main/examples/...
> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…