Why are C & Rust available to write drivers but Python cannot? Is this because Python is too abstracted, where C & Rust have access to the physical hardware without the need for an API?
Python has a much more complicated runtime system which assumes a lot of things that wouldn't be true for a driver. It could probably be adapted to work, but it's a square-peg/round-hole situation.
By comparison, C's runtime is very simple and assumes very little, so it's good for writing code in a kernel or integrated system where many OS services won't be available to you. It's also much faster, of course, and it gives more direct access to memory.
Thank you! So essentially because C gives you direct access to memory -- I remember you have to allocate array sizes which are literally contiguous blocks on your hardware -- you can control things directly. THanks
C and Rust compile to native code. Python doesn't. It's either interpreted, or run in an abstract machine (VM). Python was never really intended to interact with the actual hardware directly.
I mean, you could, there's no real technical blocker, but it'd be horribly slow. Plus many failure modes of touching hardware are very likely to break the VM process and make debugging very challenging
I think that the real blocker is raw pointers. You need to be able to read+write data to specific memory addresses for most hardware, and I don't think Python's capable of that.
- performance: implementations being interpreted, and relying on dynamic typing mean that Python is almost always slower than compiled languages.
- the run-time: Python assumes that things like allocations are always OK, and generally requires more operating system support than is available in low level environments.
Thanks for the reminder. I had it at the back of my mind that CPython is just about built as an abstraction on top of C, and so should be capable of anything C is, depending on where you wanted to draw the line between the languages.
