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.

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.

That's why you need an architect to design the project for the expected requirements. They'll ask the important questions, like:

• how many users (if it's a server)
• any long-running processes? If so, what will those be doing?
• how responsive does it need to be? What's "fast enough"?
• what's more important short term, feature delivery or performance? Long term? How far away is "long term"?
• what platforms do we need to support?
• is AI or similar in the medium term goals? What's the use case?
• how bad is downtime? How much are you willing to spend if downtime isn't an option?

You don't need all the answers up front, but you need enough to design a coherent system. It's like building a rail system, building a commuter line is much different than a light rail network, and the planners will need to know if those systems need to interact with anything else.

If you don't do that, you're going to end up overspending in some area, and probably significantly.

Upfront analysis and design is very close to independent from the technology, particularly at the I/O level