Earlier quoted context omitted.
> C is not really representative of underlying hardware anymore While I understand where this is coming from, can you suggest any language that is closer to the mental model of how the underlying hardware works than C (other than assembly)?
Well, hard to define closer as a simple dimension — but in certain things perhaps Rust — eg. SIMD is notoriously bad in C. Also, multithreading — which is not exactly a new thing either and don’t forget about pointer aliasing — though that latter is more of an optimization possibility. Fortran may also be considered as another candidate for having SoA over AoS which can potentially be more cache-friendly. But my poin…
Memory handling of course is the other big area. So many developers grown only on higher level languages have varying level of confusion about memory allocation, passing buffers around by copying vs. pointers, modifying memory vs. copy on write vs. reallocating everything. You couldn't possibly come out confused by any of this after a solid stint in C.
And just like threads, it's very valuable understanding even if later you mostly program in higher level languages.
So yes, while it certainly true that in the 80s you could squint at C code and see the generated assembly code, and that's no longer necessarily true today, it is still true that having a solid foundation in C will help tremendously in understanding what's going in the CPU and memory in ways that probably no other language (that I'm aware of) will help you learn.
I do need to spend a solid season in Rust sometime to have a deeper opinion about it!