If Rust wants to supplant C in embedded, a specification is required. I'm honestly surprised Linux is accepting unspecified code into the kernel with the addition of Rust.
No, there's will still only be one official compiler – the one written and provided by The Rust Project.
> If Rust wants to supplant C in embedded, a specification is required.
You're getting your history backwards.
C did not become successful because of its specification, it got a specification because it was successful.
Similarly, if Rust becomes successful enough, it will probably get a specification. But the popularity will drive the work on a specification, not the other way around.
I disagree. The need for a standard specification of what the C programming language is sprung from the need to ensure that multiple independent compiler implementations were actually compatible and supported the same sets of features.
If a nonstandard C ecosystem had to endure the pain of either targeting products from specific vendors or waste time maintaining a caniuse database of C features, the amount of wasted effort to just keep code building would make things too challenging and troublesome to maintain. Consequently, we would see gradual fragmentation both within the C-like ecosystem and in other potential C-like successors that ink offered minor changes.
https://lwn.net/Articles/718628/
The Linux model and the C++ 11 (as subsequently modified) model are similar in the sense that they respect how the CPU actually works, necessarily in the case of Linux and for practical low level C or C++, but in details they differ, sometimes for good reason and sometimes just because Linux was here first.
Red herring. If I recall correctly, Linus publicly stated a number of times that C's memory model is relevant for userspace code but OS development has its own requirements.
Amusingly enough, I recall that this discussion was about Rust, and the way that Rust proponents advocated pushing Rust's memory model onto Linux.