[ars]

> Wouldn't you want to choose a more "clear" language

Are you implying that another language would be more clear?

Quite the opposite, C doesn't hide anything from you. When you want to understand what the computer is doing you can tell directly from the C code. Unlike other languages where you need to understand what the language is doing first, and only then can you understand the computer.

There are time where "hiding" the computer is useful, but not here.

[cbd1984]

> C doesn't hide anything from you.

Yes, it does.

C hides cache, SIMD, registers, the stack (no multiple return values for you!), the details of the heap (malloc() either succeeds or fails, and you can't know what it's going to do until you call it), SMP, instruction-level parallelism, and the details of atomicity, all of which are relevant to OS programming.

C is a nice language. Don't pretend it's how the hardware really works.

[david-given]

...and, particularly crucially if you want to work with numbers, it also hides overflow and floating point exception behaviour. Plenty of processors support trapping arithmetic which signals on overflow and underflow, but this is practically unusable in C.

[andreiw]

There's a big difference to hiding and simply not knowing about. If you write a kernel you will need to write architecture-specific primitives (and some non-quite-primitive code, since you bring up SMP) to deal with all the categories you mentioned and some more. Regardless of the language. There is no magic language for writing kernels with a fat runtime to hide the gory details.

C is a nice wrapper around assembly. In a few cases, you wish it were a bit better specified to control the actual assembly/ABI binding a bit better. The problem I see is a lack of contract enforcement which makes introducing hard to diagnose bugs really easy. Maybe Rust will fill the gap.