10 ms·

I never understood the use case for embedding python in rust. In my experience the actual high performance code is a small portion of the overall code base, and

I never understood the use case for embedding python in rust. In my experience the actual high performance code is a small portion of the overall code base, and writing all the glue code file processing, plotting is typically much faster in python due to the excellent excellent ecosystem. I further forgo the ability to use the python repl if I do it this way around. Don't get me wrong I like rust, but I would always write the high performance code to be a module that can be imported in python, write everything in rust and the use python for some specific functions only.

sitkack 5y ago
I used to think that too, and both techniques have merit. The extending vs embedding debate has gone since Python was created, but much of that has been shaped by the difficulty in actually embedding Python, so I found myself convincing myself that embedding is the wrong choice. Contrast that with Lua where embedding and extending are about the same difficulty, there one is more likely to pick the technique that best fits the situation. One thing that is really nice about calling into Python when you need it but otherwise using your calling language and runtime is you get all the semantics of your calling language to structure the codebase and use Python as a library where needed. This is esp nice when you have security or concurrency properties that you need to hold, or if you were bootstrapping a project with Python and all of its wonderful libraries but eventually will replace or reduce the script code. One semantic nit, you probably do understand it, you just don't like it. If I have a big ETL that has lots of parts that need to run in Rust, but the cleanup code would be much easier to write in Python, I don't need a to turn my ETL into a library.

10 ms·

I never understood the use case for embedding python in rust. In my experience the actual high performance code is a small portion of the overall code base, and

by cycomanic 5y ago

sitkack 5y ago
I used to think that too, and both techniques have merit. The extending vs embedding debate has gone since Python was created, but much of that has been shaped by the difficulty in actually embedding Python, so I found myself convincing myself that embedding is the wrong choice. Contrast that with Lua where embedding and extending are about the same difficulty, there one is more likely to pick the technique that best fits the situation. One thing that is really nice about calling into Python when you need it but otherwise using your calling language and runtime is you get all the semantics of your calling language to structure the codebase and use Python as a library where needed. This is esp nice when you have security or concurrency properties that you need to hold, or if you were bootstrapping a project with Python and all of its wonderful libraries but eventually will replace or reduce the script code. One semantic nit, you probably do understand it, you just don't like it. If I have a big ETL that has lots of parts that need to run in Rust, but the cleanup code would be much easier to write in Python, I don't need a to turn my ETL into a library.