> "'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.
> "Because more or less everything is Turing-complete."
If you understand what it means, then you'd know that it means that all programming languages are comparable, from assembly to Haskell, in the sense they can all be used to do the same job. Therefore, requesting a comparison of the strengths and weaknesses of two programming languages is not a foolish request. The point of such a request is to find out where it makes sense to use a particular language. To give another example, let's say someone asks if it's a good idea to write a web server in assembly or in Go. It's certainly possible in either, but in order to explore what the best choice is then further discussion is required. Comparing a Dremel to a plasma cutter is an attempt to shut down this discussion, which doesn't help in furthering the knowledge of the participants.
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.
> "Does'nt mean you are able to break out the system and manipulate the underlying environment"
I didn't think I'd have to spell things out so excessively, but... let's extend the description then... Any Turing complete language where you can write files to storage. To give an example of why the storage is relevant, let's look at Java. Java's sandboxed in the JVM right? However, if you think about it more broadly, as long as you can freely write files to disk you can write machine code to disk. In other words, as you can write a compiler in Java, you can break out of the sandbox.
As for Minecraft, I don't know enough about it, but if it's possible to write a compiler in Minecraft then that would have the same escape hatch too. It might not be a tool you choose to code a BIOS, but we're not looking at whether something is optimal, we're looking at whether something is possible.
> "I see you keep refering to Turing completeness in other replies"
> "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."
Perhaps you overlooked the following quote as it didn't fit with what you decided you wanted to say...
"I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option."
That really isn't true in any practically meaningful sense. 'The main difference is everything is different' is not a very strong counter-argument.