> All of that may be true but it doesn't make Rust simpler than C.
Note that this is not a claim I made - in part because it’d start getting into questions of how you define “simple”. The core C language is certainly smaller, although internalizing some of the undefined bits certainly takes some time, but the question at hand was “competence” which, in a thread about security software, I have been treating as the ability to write code which not just runs but is secure. Based on how routinely C programs have exploitable bugs, I would argue that the average developer using a memory-safe language goes past the point of “can write something trivial which executes” to “can write code doing something real which is not insecure” faster.
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.
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.
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.
Note that this is not a claim I made - in part because it’d start getting into questions of how you define “simple”. The core C language is certainly smaller, although internalizing some of the undefined bits certainly takes some time, but the question at hand was “competence” which, in a thread about security software, I have been treating as the ability to write code which not just runs but is secure. Based on how routinely C programs have exploitable bugs, I would argue that the average developer using a memory-safe language goes past the point of “can write something trivial which executes” to “can write code doing something real which is not insecure” faster.