[nrclark]

Fwiw C is actually a huge abstraction over modern hardware.

It's a good representation of the PDP-11 and similar-era computers. It's also a good abstraction for modern microcontrollers.

C's view of the world is also a really poor fit for today's larger CPUs. Your computer has to jump through a ton of hoops to make itself seem C-like. C has no concept of vectorization, speculative execution, branch prediction, multiple cores, caches, MMUs, etc.

For basically any desktop/laptop/smartphone CPU, the C runtime is more like a little VM than an accurate model of the hardware underneath.

[zasdffaa]

> C has no concept of vectorization

OK, but vectorisation is exposed by the instruction set, as instructions[1]

> speculative execution, branch prediction, ... caches, MMUs

How would you expose speculative execution & branch prediction? Cache behaviour is well understood so what's wrong with it? What would you do to expose MMUs to the programmer, and what would they do with it/how would it help?

[1] but aren't there libraries that expose it just fine in a portable way?

[ncmncm]

Speculative execution and branch prediction are adaptations to compensate for C's failings as a description of desired semantics.

But they are thoroughly ingrained into the technology, and will not easily be rooted out.

[zasdffaa]

Your first sentence doesn't answer any question. The second is irrelevant. Please make some concrete suggestions.

[ncmncm]

There seems little value in "exposing" crap we would be better off not building in the first place.

The more expressive your language is, the less the runtime and hardware needs to guess about.

[zasdffaa]

So what are the $%^&* semantics we're supposed to build into the language to avoid the need for speculation via OOO exec and branch prediction. Because as a guy interested in languages you might have something to teach me, assuming you have any idea what you're talking about.

[ncmncm]

Language design is hard.