Python is actually scary fast because anybody that uses it for serious numerical work will use numpy.
ie "python is scary fast because anyone who uses it is mostly running C"
Yep. This goes for a lot of environments. It's going to take many many decades to get rid of C. Probably more than it has been here up to now.
Doesn't always mean it's particularly performant, unfortunately. The JSON lib in PHP is still C (part of Zend), but it's very susceptible to malloc failures (one big contiguous request for the whole shebang), and it's generally way faster to serialize arrays into a .PHP file you load than into JSON if you're storing it locally. I compared what I read there to the serde stuff for rust and the difference is stark.
Maybe having most of this stuff in c libs with scripts wrapped around them will make it easier to migrate. Keep the same py but swap out the lib from C to some rust that's still useful in a crate for pure rust projects.
Many of them are international standards, see ANSI INCITS 226-1994 for LISP, ECMA-262 and ISO/IEC 16262 for JavaScript, ECMA-334 and ISO/IEC 23270:2018 for C#. Lua and Python aren’t standardized, but even so, they both have a comprehensive formal spec.
> calling Python or JavaScript any efficient sounds a bit unwarranted
Both are much slower at number crunching compared to C or C++ but they aren’t that bad, either. Most JavaScript VMs feature a good JIT compiler. Some Python runtimes have JIT too.
> Consider any JavaScript desktop application, its power and memory usage.
There’re good ones, like VSCode. On average they’re indeed not great, but I think it’s just an unfortunate consequence of low entry barrier. It’s easy for inexperience people to get started with the technology. And the ecosystem is misjudged based on the output of these inexperienced developers.