A more careful reading of the article is required.
The first myth is "Python is not slow" - it is debunked, it is slow.
The second myth is ""it's just a glue language / you just need to rewrite the hot parts in C/C++" - it is debunked, just rewriting stuff in C/Rust does not help.
The third myth is " Python is slow because it is interpreted" - it is debunked, it is not slow only because it is interpreted.
Except it does. The key is to figure out which part you actually need to go fast, and write it in C. If most of your use case is dominated by network latency.
Overall, people seem to miss the point of Python. The best way to develop software is "make it work, make it good, make it fast" - the first part gets you to an end to end prototype that gives you a testable environment, the second part establishes the robustness and consistency, and the third part lets you focus on optimizing the performance with a robust framework that lets you ensure that your changes are not breaking anything.
Pythons focus is on the first part. The idea is that you spend less time making it work. Once you have it working, then its much easier to do the second part (adding tests, type checking, whatever else), and then the third part. Now with LLMs, its actually pretty straightforward to take a python file and translate it to .c/.h files, especially with agents that do additional "thinking" loops.
However, even given all of that, in practice you often don't need to move away from Python. For example, I have a project that datamines Strava Heatmaps (i.e I download png tiles for entire US). The amount of time that it took me to write it in Python in addition to running it (which takes about a day) is much shorter than it would have taken me to write it in C++/Rust and then run it with speedup in processing.
He basically says just doing that doesn't help unless very careful, due to boxing/unboxing involved. If you are careful, yes it's certainly possible. I agree with your comments around how Python is useful (but not fast) - it's the most intuitive language I've ever worked with and it just works - no surprises, no weird stuff and once you get something working then you can worry about performance without actually having to rewrite everything from scratch.
In fairness I wouldn't really call those "myths", just bad defences of Python's slowness. I don't think the people saying them really believe it - if it came to life or death. They just really like Python and are trying to avoid the cognitive dissonance of liking a really slow language.
Like, I wouldn't say it's a "myth" that Linux is easy to use.
My impression is that GvR conceded a long time ago that Python is slow, and doesn't particularly care (and considers it trolling to keep bringing it up). The point is that in the real world this doesn't matter a lot of the time, at least as long as you aren't making big-O mistakes — and easier-to-use languages make it easier to avoid those mistakes.
For that matter, I recently saw a talk in the Python world that was about convincing people to let their computer do more work locally in general, because computers really are just that fast now.
Yep, for me it confirms all the reasons why I think python is slow and not a good language for anything that goes beyond a script. I work with it everyday, and I have learned that I can't even trust tooling such as mypy because it's full of corner cases - turns out that not having a clear type design in a language is not something that can be fundamentally fixed by external tools. Tests are the only thing that can make me trust code written in this language
