Pointers. Nearer to the core. In assembly it's all pointers, pointers and pointers.

C having better support for pointers make it near to how the processor works, compared to other languages.

C is very far removed from the CPUs of the last few decades.

It's not that far from assembly languages, the nearest you can get to CPUs in terms of software.

'Nearest' is still far away in this case.

> C having better support for pointers make it near to how the processor works, compared to other languages.

Java is almost entirely pointers to heap allocations, yet I don't think anyone would argue that Java is close to how the processor works.

I also don't think that the C virtual machine is all that close to how machines actually work any more.

C has a virtual machine? Do tell more.

It appears to also be called the "abstract machine"[1].

C semantics do not work "directly on the hardware" but instead on an abstract machine that is then converted to the actual hardware.

It most often comes up when talking about undefined behavior and pointer behavior.

Some assorted reading, mostly in the context of Rust and C:

https://blog.regehr.org/archives/213

https://raphlinus.github.io/programming/rust/2018/08/17/unde...

https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html

https://www.ralfj.de/blog/2017/06/06/MIR-semantics.html

[1]: https://stackoverflow.com/questions/53100198/what-is-the-pre...

To be fair,

Assembly once worked directly on the hardware. On modern machines it doesn't.

I don't think it is fair to conflate the "abstract machine" of C with the virtual machine. There is no software virtualization at work when running C code, it is compiled directly to assembly.

I found it useful to learn just because there's so much existing code that's been written in it.

Means I can at least dig through some old codebases and understand what's going on.

Lots of higher level languages also have C bindings, so at least a couple of times in my career I've ended up writing short C modules for speed critical bits of code.

The pain of manual memory management also gave me much more of an appreciation of its pitfalls and alternatives.

C is not meant to be a beautiful language. C is meant to write programs that run as fast as possible on any CPU. The beauty of C comes from being able to tame the hardware and OS complexity to get the most speed, not from taming the complexity of the software architecture or abstract design.

If I had to pick one language to code in for the rest of my life, it would be C.

C gets out of your way and lets you do your job without buying into a lot leaky abstractions and without going to annual C conferences. C doesn't argue with you about whether something is a number or an array of bits. C is blazingly fast compared to most alternatives. C enables you to detect and handle heap overflow errors without panicking or crashing (just in case your memory is finite).

C used to have a close to bare metal semantics, and on some environments¹ still have it. So if you need low level semantics, it normally beats assembly on those environments.

The Rust people are working hard to support everything that C does, so in the future C and asm will probably not have a monopoly there. But this is still not our reality.

1 - Of course, not a PC software stack, and not on any ARM available today.