>> Most software engineers I know who have a background in EE love C, simply because it maps very well to what a processor actually does during execution.

>lol. no it absolutely does not. i have a B.S. CpE and have actually built simple processors. the C execution model has nothing to do with how silicon operates, and modern silicon in particular goes to absurd lengths to put up a façade that c programs can use to pretend they're still on a pdp-11 while the processor goes and does other things.

I'm an EE who's been writing bare-metal firmware for over ten years, and who's helped develop memory subsystems for microcontrollers. What you're saying is certainly true for PC CPUs, but the C execution model works just fine for a Cortex-M or other low-end CPU. No "absurd lengths" are needed; there's a clear relationship between:

  MOV R2, #0x400
  LDR R1, [R2, #5]

and:

  volatile uint32_t *b = (volatile uint32_t *)0x400;
  uint32_t a = b[5];

>easy example: here's a memory address. what happens when you try to read from it

The CPU puts the address on the address lines and sets some control signals appropriately, and the SRAM returns the value at that address on the data lines. (Simplifying, obviously; I'm not going to go dig up an AHB spec.)

Cache? What cache? SRAM reads are single-cycle. The flash memory probably has some caching, but that's in the flash subsystem, not the CPU. And a lot of your most important reads and writes will be to memory-mapped registers, which had better not be cached!

No, C does not express the details of the instruction pipeline or complex memory subsystems directly in the language. Neither does assembly. C also does not cover every CPU instruction -- that wouldn't be portable at all. That's what inline assembly and compiler intrinsics are for.

C strikes a balance between portability and closeness to the hardware while remaining a small language. It does this very well, which is why it has historically been so popular, and still is for some purposes. Not all software is CPU-limited data processing on a 64-bit server.

Also the "PDP-11 facade" is needed so that the thing can be programmed in assembly language without the board support people doing bring-up tearing their hair out. A sane assembly language that you can read instruction by instruction to understand the abstract effect is necessary for more than serving as a C compiler target.

> [citation needed]

Runs just about every computer from the tiniest microcontroller to the largest supercomputer. Has been doing so for 50 years, despite a constant parade of miracle languages that were going to replace it Real Soon Now.

When Miracle Language of the Day actually does what C does, across the same variety of hardware, I will be the first to congratulate it and its designers.

But I don't think that's going to happen any time soon.

It runs on all hardware because hardware manufacturers support it, which they essentially must do because that's what's expected. It's a self-fulfilling prophecy (and arguably a vicious cycle).

Or, it’s a virtuous cycle of people recognizing a valuable tool and giving back to its ecosystem by developing for it (even if that’s not intended–it’s a second-order effect).

It can also be seen on another axis, that of organic growth versus what each new miracle language tries to be, which is a centrally planned and all-encompassing solution, which isn’t possible without the entire rest of the industry just stopping and waiting for it all to be made to work.

C already works. So people work with it.

It's "organic" because, as this article is pointing out, creating alternatives is really difficult due to this exact lock-in, both at the OS level and at the hardware-vendor level.

You shouldn't need a "miracle language" or even an "all-encompassing solution" to have a chance to break free of this.

> creating alternatives is really difficult due to this exact lock-in,

That is nonsense.

As I noted below, low-level OS internals have been reimplemented numerous times, by small teams of volunteers at that.

If you want to "break free", buckle down and do the work.

Sure. You can re-implement everything starting with the Kernel, as long as you don't have to interface with any of the C microcode on the hardware itself. And, yeah, people are doing this, for instance with Redox OS.

But if you actually want to program something usable in conjunction with existing software, such as Linux, you need to use the C ABI. There is no alternative.

> is this a joke. you literally cannot write containers in C unless you commit to heap-allocating everything and storing it as void*

Who cares long as the interface is type-safe?

> [citation needed]

Good joke, yeah. The whole "can you give me a source for that?" thing is getting quite old.

Oh, what? You were serious?!