Isn't this exactly how python works with pytorch, polars, and similar very fast libraries?
I would describe polars a library to work with data (https://www.pola.rs/). So we have a high-performance library in Python to work with generic data.
I think that covers a lot of cases, since you can transform arbitrary parts of a program into data. Ask any lisp fan.
Typescript is great, and the approach of having native high-performance modules works great for Python. You can offload, if you want to, a big part of your program to high-performance libraries. Maybe it is not the most elegant, but it works.
Python is not cpp, but if it fits your use-case, it can be quite performant.
https://stripe.com/blog/sorbet-stripes-type-checker-for-ruby
> Unfortunately we were starting to see Ruby come apart at the seams: new engineers found it hard to learn the codebase, and existing engineers were scared to make sweeping changes. Everyone faced a constant tradeoff: run the fast, local tests which might not catch many breakages, or run all the tests, even the slow ones. Ruby was becoming a source of friction more than a source of productivity.
I'm not saying you can't make good products with inferior languages.
JS maybe (well TS, not JS; you'd be a fool to use actually JS) but I've seen more than a few projects strangled by their choice of Python and the terrible performance it comes with.
People always say "it doesn't need to be fast"... until it does and it's too late. Or "we'll write the bottlenecks in C++"... until you realise that it's all bottleneck.
Mercurial and Scons are obvious public examples.
Language does make a difference, despite everyone being polite and saying it doesn't. Of course that doesn't mean it is the only or even biggest factor.