C compilers already optimize for CPU instruction order on multi-issue pipelined CPUs. Multithreading in C, however, is left as an exercise to the coder. You manually need to use locks and make sure no race conditions are occurring, which is hard in large programs. Also, no function is thread safe unless you're explicitly told so.

I don't use Rust very much, so someone correct me if I'm wrong, but the ownership and borrowing system makes the compiler fail if you transfer data to child threads and then use it in the main one. It's just safer to parallelize code, and you'll do it! (unlike in C, where it may be better not to risk it)

> Multithreading in C, however, is left as an exercise to the coder.

Well, it is a systems implementation language, so it cannot, and should not, impose too many guardrails.

And yes, sometimes systems implementations need to do things that even all the checks built into Rust would scream loudly about. Rust, which is also meant to implement system code with, acknowledges this duality, that's why the `unsafe` keyword exists.

And while the complexity of avoiding race conditions does exist, we have good solutions for it. One such solution is CSP. Passing state and synchronizing via messages is an incredibly natural and logical way to think about the structure of concurrent codebases.

Rust is also a “system implementation” language.

Yes? I said so in my above post?

> Rust, which is also meant to implement system code with

Rust prevents data races by the help of the borrow checker (by preventing multiple threads using the same resource concurrently), and it also helps by disallowing sending objects to other threads if they were not marked as capable of such.

The principal difference is that rust constrains aliasing somewhat more than c. The practical differences currently are more relevant to compilers than cpus, since architectures do not provide a way for programs to provide aliasing information to the cpu, and so cpus do their alias analysis dynamically, in a way that works as well for rust as for c. But one can imagine an architecture which allowed programs to supply aliasing information statically. This would be relevant for both c and rust, just somewhat more so for rust.

> C CPU and memory model is based on a single-core, linear-memory background that belies the complex internals of modern CPUs

This has become a popular meme, but it just ain't so.

Assembly language has this model, and the complex internals of modern CPUs are largely hidden from it as well.