4 ms·
With GCC adding Rust support there is no longer one "official" compiler. In many people's eyes GCC will be considered "the" Rust compiler. If Rust wants to sup
by suprjami 4y ago
With GCC adding Rust support there is no longer one "official" compiler. In many people's eyes GCC will be considered "the" Rust compiler.
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.
- Macha 4y agoLinux's C code doesn't stick to the C standard either, it uses plenty of GCC extensions, and it's not clear Clang would have implemented all of them if it wasn't for their use in the Linux kernel. So a language specification is not that high on the Linux priorities list.
- tialaramex 4y agoLinux doesn't even obey ISO C's Memory Model. Linux was multi-processor many years before ISO C11 documents a Memory Model (the same one as C++ 11) and so it had many years to decide how this stuff should work in practice on actual multi-processor hardware. https://lwn.net/Articles/718628/ 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.
- simplotek 4y ago> Linux doesn't even obey ISO C's Memory Model. 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.
- madmoose 4y ago> With GCC adding Rust support there is no longer one "official" compiler. 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.
- simplotek 4y ago> C did not become successful because of its specification, it got a specification because it was successful. 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.