[cgreerrun]

> I do not recommend anyone use python for anything performance sensitive

My default philosophy is to use python _until_ you find something that is performance sensitive, and then make a C/C++ extension for the slow bits. Pybind works great for a hybrid Python/C++ codebase (https://pybind11.readthedocs.io/en/stable/).

Then you can develop and prototype much quicker w/ Python but re-write the slow parts in C++.

Definitely more of a judgement call when threading and function call overhead enter the equation, but I've found this hybrid "99% of the time Python, 1% C++ when needed" setup works great. And it's typically easier for me to eventually port mature code to C++/Go/etc once I've fleshed it out in Python and hit all the design snags.

[cgreerrun]

If you've never used Pybind before these pybind tests[1] and this repo[2] have good examples you can crib to get started (in addition to the docs). Once you handle passing/returning/creating the main data types (list, tuple, dict, set, numpy array) the first time, then it's mostly smooth sailing.

Pybind offers a lot of functionality, but core "good parts" I've found useful are (a) use a numpy array in Python and pass it to a C++ method to work on, (b) pass your python data structure to pybind and then do work on it in C++ (some copy overhead), and (c) Make a class/struct in C++ and expose it to Python (so no copying overhead and you can create nice cache-aware structs, etc.).

[1] https://github.com/pybind/pybind11/blob/master/tests/test_py...

[2] https://gitlab.unistra.fr/benzerara/pybind11/-/tree/master/e...

[synergy20]

what about CFFI?

[nijave]

>and then make a C/C++ extension for the slow bits

I've found cross language bindings to be pretty easy with Python. If you want something with memory management, you can use cgo

[synergy20]

isn't cgo for golang?

[mlyle]

You're still kinda stuck with concurrency of the python code itself though. It sure would be nice to be able to just throw cores at problems for awhile.

Computers are cheap, and people are expensive.

[KptMarchewa]

You can spawn threads as much as you want from native language.

[mlyle]

Sure, and if you can't get stuff in and out of Python objects with concurrency, it doesn't help you much a lot of the time. Plus, again, computing is cheap: it'd be nice to use all my cores before I spend a lot of effort optimizing and rewriting things in native code.

[VHRanger]

That's a data layout problem largely, though.

If your data is fragmented across a bunch of small containers/classes, passing it around will be expensive whichever the method (either passing to C++, or just in terms of cache efficiency).

If you just pass an array of data back and forth it's cheap.

[mlyle]

> If you just pass an array of data back and forth it's cheap.

Yes, and numpy is great, and all. Python works great as glue to marshal things to and from native code and do inexpensive (but possibly complicated) bits of control logic.

But if I'm trying to deal with large numbers of client requests, say... the lack of concurrency in python itself really hurts. Sure, I can punt almost everything to native code, but what's the point in having Python at all, then?

Not all problems have state that can be shared well across Multiprocessing or completely externalized to large lumps that travel to native code in a few calls-- I'd actually say these are special case exceptions than the rule.

[VHRanger]

Right, if your issue is that you're getting a ton of small, individual API calls, python will suffer.

At that point you'd look to Go or another language, and also carefully choose the REST API framework you're setting up.

Note that having a solution setup where the end result is "a ton of small, individual API calls" could possibly indicate a bad system architecture.

[bb88]

I think the question is how much more cost does it take to move the code from python to C/C++/Rust/whatever? That's a human problem until ChatGPT can solve that problem for you.

[KptMarchewa]

Rust with Py03/Maturin fills that role for me. And it works with Java/JNI too.

[jacobr1]

I can also recommend Cython as an alternative to Pybind for the extension wrapper.