> "'The main difference is everything is different' is not a very strong counter-argument."
That wasn't my counter argument, and I can't work out what you misinterpreted about what I said to get that impression.
My point was, unlike a Dremel and a plasma cutter, Rust and Python can be used for the same tasks. As they're both Turing-complete, anything you write in one can be written in another. The differences I suggested were to highlight the relative strengths, or in other words how much work you'd need to put in to get the desired result.
To be clear, if you hadn't tried to dismiss the GP who requested information about how Python and Rust compared to each other, I wouldn't have replied.
If that's your impression, then I'd suggest Python is used for more than you're currently aware of. Here are two examples of Python being used for "low level stuff":
Nothing against Python (I'm using it) , but those solutions have huge performance impact comparing C/Rust on bare-metal. Interrupt handling, GPIO operations are orders of magnitude slower in python. Take such simple board and run basic bit-banged gpio PWM. You need "beefy" Cortex-M family to get similar performance that you can get with 8/16-uC with C. Nice for hacking stuff but I would't trust my AC conditioner firmware running months without power cycle on interpreted language :) C/Rust gives you static analysis of memory usage so you can predict sw memory usage. With Python VM single bug in it can shutdown your code or eat all heap. Maybe now maybe after six months running your code. Nice hacking tools thou.
> "those solutions have huge performance impact comparing C/Rust on bare-metal"
I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option.
> "You need "beefy" Cortex-M family to get similar performance that you can get with 8/16-uC with C."
In the case of MicroPython, people find it usable on platforms like the ESP8266, which is less powerful than a "beefy" Cortex-M. As before, I don't deny that there is a performance overhead compared to C, but it clearly has some traction in the embedded space.
If you understood what MyHDL is doing, you'd know that doesn't matter.
Furthermore, most Python implementations are built using C, including the canonical one (CPython). It is possible to have performant Python implementations without using C, if that's what you're getting at.
No I am not simply talking about performance. I see you keep refering to Turing completeness in other replies, even condescendingly implying that your HN peers does not understand it, when you are clearly the one whose understanding needs to mature. A turing complete system is one where the rules are powerfull enough that you are able to implement "anything" INSIDE of them. Does'nt mean you are able to break out the system and manipulate the underlying environment, or even infer anything about how it's implemented. Just to bring my point to the extreme: Minecraft is turing complete. Does'nt mean you can bootstrap your cpu with. You can in theory emulate your cpu on top of it though.
Actually you seem to suggest that not even performance is of any hindrance to python. In which case I'm lost for words. You win.
The main differences are found in tooling, library ecosystems, development speed and runtime overhead.