Python is perfect as a "glue" language. "Inner Loops" that have to run efficiently is not where it shines, and I would write them in C or C++ and patch them with Python for access to the huge library base.
This is the "two language problem" ( I would like to hear from people who extensively used Julia by the way, which claims to solve this problem, does it really ?)
I have used Julia for my main language for years. Yes, it really does solve the two language problem. It really is as fast as C and as expressive as Python.
It then gives you a bunch of new problems. First and foremost that you now work in a niche language with fewer packages and fewer people who can maintain the code. Then you get the huge JIT latency. And deployment issues. And lack of static tooling which Rust and Python have.
For me, as a research software engineer writing performance sensitive code, those tradeoffs are worth it. For most people, it probably isn’t. But if you’re the kind of person who cares about the Python optimization ladder, you should look into Julia. It’s how I got hooked.
As a sibling comment mentions, yes it does. Just don’t expect to have code that runs as fast as C without some effort put into it. You still need to write your program in a static enough way to obtain those speed. It’s not the easiest thing in the world, since the tooling is, yes, improving but is still not there yet.
If you then want to access fully trimmed small executables then you have to start writing Julia similarly to how you write rust.
To me the fact that this is even possible blows my mind and I have tons of fun coding in it. Except when precompiling things. That is something that really needs to be addressed.
This problem has been solved already by Lisp, Scheme, Java, .NET, Eiffel, among others, with their pick and choose mix of JIT and AOT compiler toolchains and runtimes.
No, those languages have not solved it. None of the languages you list there are actually as fast as C for tight inner loops, they sometimes get close under certain circumstances, but they're still very much 2nd class languages in terms of performance.
They're only "fast" compared to slow interpreted languages like Python.
Yes they have, because those microbenchmarks are tailor made for the winner, using a very specific compiler implementation with language extensions, which apparently is only valid if the language happens to be "C".
This is such bizarre cope. It's okay for a language to not have first-class numerical performance characteristics. Langauges can have other reasons to exist. Just don't like about the performance, that doesn't help anyone.
It is not coping, it is a two measures, two weights attitude when putting C into a pedestral, you even missed on C++, which all major modern C compilers are written on, and share the backend with some of those languages.
This is the "two language problem" ( I would like to hear from people who extensively used Julia by the way, which claims to solve this problem, does it really ?)