Gamedev - at least engine dev - bears some relation to the embedded & performance-critial world. You have this conflict between needing extremely performant code, as close to the metal as practical, but also needing rapid iteration and to represent high-level logic cleanly. This is why you almost always end up with the juxtaposition of a C++ core and an embedded scripting language like Lua.

Python isn't really performant enough, or at least hasn't been in the past. Performance still matters, even for a scripting language.

In general, if your engine does what you want right out of the box with no modifications, you can go a long way to writing a game in the scripting language and - if you're not pushing it hard - not suffer any real performance issues. But as soon as you want to chase framerates, or do something unique or time-critical or computationally difficult, which is often, you 100% need that low-level language.

It's true right now though there are a lot of people working on different ways to get python to have near native performance. I'd say it could be a fixable problem.

I was listening Lex Friedman's podcast featuring Chris Lattner a few months ago. He's is working on Mojo, which is basically a fast superset of python that can be fast (if you opt in to a few things) and worst case just falls back to being as fast as regular python. The intention is to give people enough means that they can optimize such code to be actually fast or just run it as is.

I'm not much of a python developer myself, even though I do have to deal with it occasionally. I liked the point that he made that, for whatever reason, there are just a lot of people using python and getting access to that community of people is a good way to get traction for your tool or technology. He was talking about machine learning specifically. A lot of the experts in that field are using python. Of course all the difficult bits and bobs are outsourced to native libraries. His vision is that a lot of that stuff should be written in mojo/python and that there are no good reasons why that should be any slower.

Probably removing the gil will help (everything blocking is not cool). And the language could use some better primitives for dealing with things like co-routines. They are kind of nice to have in asynchronous code bases like games or UIs. But those are things that could be fixable and might benefit the rest of the ecosystem.

> Im thinking of libraries like torch, tensor flow, or pandas.

Well the overhead doesen't really matter that much, who cares if you have to wait 10ms or 100ms etc. So yeah rewriting the Python bits is not worth it.

It's an entirely different use case though. In game dev you need fit your frame into 16ms or 32ms and you calling the methods hundreds or thousands of times every second etc. it all adds up.