What if I told you that even if you were using C/C++, you'd still need to be using library functions? Because the code, ultimately, doesn't run natively, it calls Fortran, Assembly and CUDA libraries.

You cannot directly program in whatever CUDA compiles to because it's proprietary and GPU model-specific, so why bother? Researchers chose Python not because they like snakey-boys or enjoy British comedy, they chose it because it is adequate to do research in, unlike C or C++, which are horrible to work with and too hideous to read and understand even if a pro writes them, let alone some researcher.

Ultimately Python code is easier to maintain and work on, and there are more developers as opposed to C/C++, so of course companies will use it over whatever C++ API exists for DL libraries.

As for your Rust/Go question, although Go has some potential it has no community to work with. It is also harder to use than Python. There is almost no benefit of using Go over Python even if the decision was to be made now, let alone transfer, other than Go's nice concurrency model. Now, why would you use that when from joblib import delayed, Parallel does the trick? So far, the biggest problem Python has with concurrency is its lack of a good shared memory API, which is probably going to be fixed in a year or so now that it is part of Python. But this lack of API does not significantly impact Python, because you'd do this kind of stuff via a C module anyways.

As for Rust it will probably never become a serious contender for research and development because it is even more hideous and complex than C/C++ are. It is also slower, so, what's the point? Unless you want to double the average wages of people in DL and kill 90% of jobs since barely anyone can use Rust effectively.

using vectorized operations isn't just a design choice of the language you're programming in. It's a fundamental concept for optimizing code. for loops don't magically become fast just because you're using C++. For example, google "vectorize for loop c++" there are tons of results. In general you don't want to be using loops, especially for large scale data problems.

1. I mean at that point why not start using C for most efficient processes? I think you’re thinking that for loops are kind of this “base” truth when it’s yet another tool that happened to come first in the history of programming. Vectorized operations are a godsend and have allowed programmers to graduate beyond for loops. I don’t have to write out my little optimized c++ function every time I want to run an apply statement or whatever. Specific to ML, I don’t have to manually format my data structure to hook it up to pytorch; I just gotta have a pandas data frame with some minor tweaks to stick it into a neural network.

The GIL has nothing to do with ‘flexibility’

The fast ones are not flexible.

Python is flexible, you can do loops.

Of you want to be fast, you won't be doing loops in C++ either.

Overall, you sound confused.

It sounds like your issues are more about PyTorch than Python itself. The need for vectorization is not specific to a language, though some libraries make it easier than others. If you want automatic vectorization, have a look at Jax, which has grown tremendously in the past couple years.

You should try Julia!