What if I want to know how registers are used and allocated in a program? Most C compilers ignore "register" annotations, and with good reason- they hamstring the compiler's ability to optimize, which is usually a completely opaque process from the programmer's point of view in the first place.
Why have a type system that includes implicit coercions between types, sometimes with different internal representations? (Just imagine an int promoting to a float.) Doesn't that obscure the "real meaning" of the program, or is it merely a detail you find uninteresting? C is not the only language that makes these low-level concepts accessible, and C does not represent the "floor" with respect to making the behavior of hardware explicit.
If what you're actually getting at is that C is the most popular language today that exposes all of those things, it sounds less convincing- Systems languages cannot advance if we take C's position as given.
You're right, C is the most popular language with the least amount of magic between you and assembly. It's a useful balance of abstractions on top of assembly without a total loss of the processor model.
This isn't less convincing to me, I would never argue that someone learn C instead of all other languages. But I do believe that knowing C makes you a better programmer in all (current popular production) languages.
Re: your point about systems programming not advancing...I didn't mean to imply that C was "perfect" (in the Latin sense, meaning "done, finished"), just that it's the best we have for many things.
I do really like Go, and wish I could use it more, for non-personal projects.
Having really bizarre type conversions can allow for brilliant code in some cases - the Quake fast inverse sqrt function contains a float->int coercion, iirc.
Why have a type system that includes implicit coercions between types, sometimes with different internal representations? (Just imagine an int promoting to a float.) Doesn't that obscure the "real meaning" of the program, or is it merely a detail you find uninteresting? C is not the only language that makes these low-level concepts accessible, and C does not represent the "floor" with respect to making the behavior of hardware explicit.
If what you're actually getting at is that C is the most popular language today that exposes all of those things, it sounds less convincing- Systems languages cannot advance if we take C's position as given.