I've tried repeatedly over the last 25 years, in Python, with a lot of success for large amounts of computation. Architecture and algorithms matter so much more

I've tried repeatedly over the last 25 years, in Python, with a lot of success for large amounts of computation. Architecture and algorithms matter so much more than limitations like the GIL, slow function calls, etc. And in my experience, Python gives me the time and mental bandwidth to focus on architecture and algorithms. It's hard work, but in my experience it's not as hard as getting the same level of success without a very high level language gluing things together. One memorable situation was sitting in a sales meeting in ~2003, showing the speed of one such system. We let the potential client customize some input data, then ran a computation (the point was to show that something that used to be a batch process could now be interactive). It took ~30 seconds on our laptop running on battery power. On the spot, their CTO accused us of lying because it took days of dedicated mainframe time for them to run the same computation. Our sales person later asked if we could introduce configurable delays that we'd only turn on during sales presentations so that it would be easier to believe and less threatening. Our original implementation was 1000s of lines of Python and would take weeks to run. Over time we optimized that down to about half a day of run time. Then we figured out that the thing taking all the time was equivalent to finding shortest paths in graphs over and over again. So we found an open source C extension with a nicely optimized implementation of Dijkstra's algorithm and our Python code reduced to 100s of lines and was literally unbelievably fast. Today I'm working on a simulation system for use by people who are experts in game theory. The thing being simulated is an algorithm in an online system (that almost everyone reading this in the US has used) that does server side optimization of the selection and placement of content during web / mobile app page loads. We want to share code between online and simulation to avoid semantic differences. The online system is in Python. Python is what our math folks know. The algorithm currently runs tens of millions of times per day online with billions of inputs, all on a small cluster of machines. Online we need low latency, O(1 ms) per run. Offline we need as much computational bandwidth as we can get to keep math folks going - improvements to this algorithm can mean big revenue wins. We haven't shipped yet, but the current version replays hundreds of millions of runs (10s of billions of inputs) per minute in a large Spark cluster (developers only ever see Python, not the PySpark API). The online backend runs the exact same Python code in O(100 µs) with a Python backend (only one non-builtin extension is used online - Pyrsistent, which gives us efficient immutable data structures - the online backend uses FP concepts to avoid complexity). In my experience, running up against things like the GIL for doing large amounts of computation means I'm stuck in a local optimum for speed. Backing up and thinking about my architecture / algorithms gives me a real chance of making improvements that show that the GIL wasn't my core issue. Eliminating the GIL might get me an order of magnitude speed improvement (often at the expense of more complicated code). Finding better architecture / algorithms often gets me several orders of magnitude of speed improvement and simplifies my code at the same time. A very high level language that is good at gluing things together gives me more time / options for doing that.