What I mean is that the performant libraries of the ML/AI python ecosystem are all written in C or another high-speed compiled language. The speed of the underlying execution is not meaningfully affected by the speed of the Python interpreter. If CPython 3.12 came out with a huge performance regression and ran 50% slower than 3.11, these ML programs would run at almost exactly the same speed they do today.
Why wouldn't it also be true for mechatronics? Have some native bindings for C libraries then you can write Node or Python and still use the machine code where needed. Speaking of which:
> The speed of the underlying execution is not meaningfully affected by the speed of the Python interpreter
Wouldn't both JIT vs not JIT have an impact on speed, and also some of the "heuristical" stuff V8 does?
I wouldn't rule out JavaScript for mechatronics, everything ends up in JavaScript.
I suppose my knee-jerk reaction was driven by "interpreted languages are not suitable for low-resource machines," because the fixed overhead of booting up a Javascript or Python interpreter/JIT are comparatively higher in embedded environments. But the space nowadays is a lot bigger/wider than the traditional "embedded" space (where 4KB of RAM is a luxury), so there's no reason a drone or robot can't have a few gigs of RAM and multiple cores to use. So Javascript/Python is probably fine for a huge category of mechatronics applications.
