3 ms·

Let's say I have some new piece of hardware that is exotic enough that no high-level language is available for it yet. I think it's obvious that writing a C co

Let's say I have some new piece of hardware that is exotic enough that no high-level language is available for it yet. I think it's obvious that writing a C compiler is generally an easier task than writing a Rust compiler. As long as that's true, and I can leverage C code on my new hardware much more easily than Rust code, Rust can't replace C. An "average developer using a memory-safe language" can't go anywhere if that language doesn't run on the machine.

acdha 6y ago
Do you think average developers implement C compilers and toolchains on novel hardware frequently? That’s a pretty niche case and the vast, vast majority of C code is running on a handful of well supported architectures. It’s also not like that’s trivial even for C - I remember how many decades it took companies employing large numbers of engineers to do so – and these days a better question is something like how long it would take to implement an LLVM backend.
- carapace 6y ago
  Here's an example of the kind of thing I'm talking about, from the HN front page today: "Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun" https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/ I apologize in advance if it seems like I'm moving the goalposts. You're right that implementing a C compiler isn't a common or trivial task. My point is that implementing a Rust compiler is a much more complex task. > the vast, vast majority of C code is running on a handful of well supported architectures. Irrelevant. How much C vs Rust (vs Zig or D or ...) is running on the long tail of hardware? FWIW, if Rust displaces C on the lion's share of machines, that's great. I'm not against Rust, or in favor of C. > these days a better question is something like how long it would take to implement an LLVM backend. Yes, absolutely, I agree. Ideally you would have a program that takes as input a machine description and emits as output a correct Rust (or C or Zig or D or ...) compiler for that machine.

acdha 6y ago

Do you think average developers implement C compilers and toolchains on novel hardware frequently? That’s a pretty niche case and the vast, vast majority of C code is running on a handful of well supported architectures. It’s also not like that’s trivial even for C - I remember how many decades it took companies employing large numbers of engineers to do so – and these days a better question is something like how long it would take to implement an LLVM backend.

carapace 6y ago
Here's an example of the kind of thing I'm talking about, from the HN front page today: "Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun" https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/ I apologize in advance if it seems like I'm moving the goalposts. You're right that implementing a C compiler isn't a common or trivial task. My point is that implementing a Rust compiler is a much more complex task. > the vast, vast majority of C code is running on a handful of well supported architectures. Irrelevant. How much C vs Rust (vs Zig or D or ...) is running on the long tail of hardware? FWIW, if Rust displaces C on the lion's share of machines, that's great. I'm not against Rust, or in favor of C. > these days a better question is something like how long it would take to implement an LLVM backend. Yes, absolutely, I agree. Ideally you would have a program that takes as input a machine description and emits as output a correct Rust (or C or Zig or D or ...) compiler for that machine.