Ease of access to the underlying hardware in your programming language is only ever needed for embedded programming in the current year. Change my mind.
There are actual use cases where direct memory access and pointer magic can be very efficient or almost necessary.
We work a lot with large images and basically always the first steps are some pointer operations.
When you're writing code involving global state and interrupts, and any access to an integer larger than a u8 needs to be surrounded by cli() and sei() just for guaranteed atomicity, then you will truly come to value rust's statically enforced thread / memory safety.
Are those still in use? With how cheap modern MCUs got, it kinda seems like it often makes more sense to get smth a bit more powerful and get the benefits of overall easier and faster development. May be wrong here, tho -- it's not like I compared numbers or something
Addit: I mean, 8 bit may easily still be a bit cheaper, yet corps will likely spend more than the difference in price paying devs
For years I wrote embedded C for 8 bit microcontrollers used in industrial controls.
Never again.
Rust is by far a better language for embedded. The only times I would consider it reasonable to write embedded code in C is if you're doing it for fun, or you depend on an existing and well tested / audited codebase or library and your application logic is less complicated than rust to C FFI.
Even then, you won't find me contributing to that effort.
Or micropython. That might sound nuts, but consider that Python was released two years after the 486 and two years before the Pentium. The RP2040 microcontroller has a far higher clock rate than those, has dual cores, and costs a dollar. It may lack RAM compared to some of those desktops at the time, though.