And at that point you’ll also have a better idea of the problem and solution.

Python is also pretty good for production, provided you're using libraries optimized in something faster. Is there a reason you didn't use Open3D's Python library? I'm guessing you'd get close to the same performance of the C++ code in a lot less time.

That said, if you're doing an animation in 3D, you should probably consider a game engine. Godot w/ GDScript would probably be good enough, though you'd spend a few days learning the engine (but the next project would be way faster).

If you're writing a performance-critical library, something compiled is often the better choice. If you're just plugging libraries together, something like Python is probably a better use of your time since the vast majority of CPU time can generally be done in a library.

Sounds like an excellent idea, I'd be surprised if it isn't happening.

Or you could use cython, which is much easier to integrate with a python project. It is only marginally slower than Rust but a little less safe. Numpy libraries are usually the fast. Numba is a little clunky, but can also speed up code. There's lots of options to speed up python code.

Sure, I was being mildly facetious, but pointing to a better pattern, the nature of python means it is, barring some extreme development, always going to be an order of magnitude slower than compiled. If you're not going to write even a little C, then you need to look for already written C / FORTRAN / (SQL for data) / whatever that you can adapt to reap those benefits. Perhaps a general understanding of C and a good knowledge of what your Python is doing is enough to get a usable result from a LLM.

I have an alternative anecdote.

My coworker is a Ph.D in something domain specific, and he wrote an app to do some complex simulation. The simulation worked well on small inputs (like 10), but took minutes on larger inputs (~100), and we want to support very large inputs (1000+) but the program would get killed with out of memory errors.

I (CS background) looked over the code and pointed out two issues:

• bubble sort in a hot path
• allocated all working memory at the start and used 4D arrays, when 3D arrays and a 1D result array would've sufficed (O(n^4^) -> O(n^3^))

Both problems would have been solved had they used Python, but they used Fortran because "fast," but it doesn't have builtin sort or data structures. Python provides classes, sortable lists (with quicksort!), etc, so they could've structured their code better and avoided the architectural mistakes that caused runtime and memory to explode. Had they done that, I could've solved performance problems by switching lists to numpy arrays and throwing numba on the hot loops and been done in a day, but instead we spent weeks rewriting it (nobody understands Fortran, and that apparently included the original dev).

Python lets you focus on the architecture. Compiled languages often get you stuck in the weeds, especially if you don't have a strong CS background and just hack things until it works.