[uoaei]

There are very real limitations to the tooling approach summarized as "slightly more ergonomic APIs to underlying C/C++ code" that is currently dominant in Python qua ML. One of the biggest is of course extensibility, which, if difficult enough (as is the case in most Python ML tools unless you're extending only at the relatively slow Python layer) drastically hinders progress in making tooling better while keeping performance good.

Other languages have certain features that make extension and integration feel like first-class concerns which lowers the barrier to contributions from a wider range of people and also helps keep e.g. dependencies and build processes relatively simple.

[nologic01]

I would not necessarily disagree with any of these points, just sceptical that these are enough to create the substantial investment by diverse actors to create real alternatives. The example of Julia non-adoption is very important to keep in mind.

Python was not designed for ML, it happened to it, the way Android happened to Java etc. Loosely speaking the Mojo project serves a function similar to that of Kotlin in the Android mobile world. Trying to remedy some recognized friction points while maintaining the benefits of a widely established ecosystem.

Obviously not holding a crystal ball: if the ML hype mutates into something more permanent and very widely embedded across different verticals (not just the big tech sponsored pytorch / tensorflow platforms and use cases) and if the Python/C++ combo becomes a recognized bottleneck then the conditions might spark another approach.