[okaleniuk]

And yet again the speed argument. It's not about the langauge really. If you want, you can make Python program run fast. Anecdotal evidence: https://wordsandbuttons.online/outperforming_everything_with...

But you don't want that. You want the underlying libraries to be fast and Python code to be cute. And that's the right way to go.

Part of my department's job is adopting the researchers' prototypes in Python and making them fast in C++. First of all, it's not about making them radically fast, it's about making them some 10% - 100% faster. I guess, the best I've heard about was 3x. Second, there were cases when C++ remakes were even slower than the prototypes in Python.

This phenomenon has an explanation. If 99% of what it does is done by NumPy, then we really compete with NumPy.

For instance, it might be built for more recent architecture and using better superscalars. Researchers can afford the very recent builds but we have to support a lot of users with a lot of PCs so we're basically stuck in 2010 with out target architecture.

And even this small detail matters more for the performance than the glue it was all brought together with.

[nunez]

Agree. Very, very few people/use cases require near-metal performance. Python is fast enough for most use cases while being much easier to start with and get proficient at than C/C++.