That's exactly the point, if your machine is anywhere near 'standard' (as in not a SIMD or something exotic) then C is as close as you can get to it without going to assembler.

Not any longer. I don't know how C models the kind of massive parallelism that is becoming mainstream right now.

The only reason you know what the C you write will end up doing on the machine is because you are generally not doing much when you're working in C.

If you want to get productive work done, you'll be leveraging lots of libraries written by third parties, and you have no more insight into how they are working when you're invoking them with C than Ruby, Python, Java, C#, or any other language.

A C program that accesses the memory will do so in an extremely predictable way, if I lay out a memory structure, a piece of code and an access pattern then I can be very sure about how that will interact with things like the caches.

In other languages where there is more 'under the hood' that is a lot harder.

Libraries don't enter in to the problem, that's another level altogether.

While it's true that library code written by third parties might be less (or more) efficient than the code you wrote, even those libraries will have the luggage of the underlying implementation of the language.

In C there is no implementation underneath, it is a 1:1 correspondence with machine instructions.

That is the reason that kernel code tends to be written in C.

In C, you deal with so many trees, it sure feels like you're right there in the woods. But actually, if you're dealing with things on a tree by tree basis, you're not getting much done. And you can pretty lose your way by focusing on navigating territory efficiently at that level, but not keeping track of the overall goal.

As to whether kernel code should be written in C, that is a different matter. C is not a good map to von Neumann architectures because it doesn't model shared code and data in memory - C doesn't have a good representation for writing code at runtime. Most code written in C will not be the most efficient possible code for this reason.

Modern developers have gotten so used to the fact that C is "low level" that they tend to forget how low really low level coding is. There's a ton of "high level" language features in every 3GL, and that includes C. The abstractive distance from machine code to a language like C or Pascal is far, far higher than it is between C and Python.