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.