Sure, and we use those, like numpy, scipy, and tensorflow. Python is best when gluing libraries together, so the more you can get out of those libraries, the better.

Python isn't fast, but it's usually fast enough to shuffle data from one library to the next.

Exactly. We have hundreds of thousands of lines of code that work reasonably well. I think we made the important decisions correctly, so performance issues in one area rarely impact others.

We rewrote ~1k lines of poorly running Fortran code into well-written Python code, and that worked because we got the important parts right (reduced big-O CPU from O(n^3^) to O(n^2^ log n) and memory from O(n^4^) to O(n^3^)). Runtime went from minutes to seconds in medium size data sets, and made large data sets possible to run (those would OOM due to O(n^4^) storage in RAM). If you get the important parts right, Python is probably good enough, and you can get linear optimizations from there by moving parts to a compiled language (or use a JIT like numba). Python wasn't why we could make it fast, it's just what we prototyped with so we could focus on the architecture, and we stopped optimizing when it was fast enough.

We also do "real work," and that uses libraries that use C(++) under the hood, like scipy, numpy, and tensorflow. We do simulations of seismic waves, particle physics simulations, etc. Most of our app is business logic in a webapp, but there's heavy lifting as well. All of "our" code is Python. I even pitched using Rust for a project, but we were able to get the Python code "fast enough" with numba.

We separate expensive logic that can take longer into background tasks from requests that need to finish quickly. We auto-scale horizontally as needed so everything remains responsive.

That's what I mean by "architected well," everything stays responsive and we just increase our hosting costs instead of development costs. If we need to, we could always rewrite parts in a faster language, provided that costs less than the development costs. We really don't spend much time at all optimizing python code, so we're not at that point yet.

That being said, I do appreciate faster-running code. I use Rust for most of my personal projects, but that's because I don't have to pay a team to maintain my projects.