> Yep. Which one will be better at debugging when things inevitably go wrong?
I think you're dramatically under-estimating the amount of extra work a C developer has to do, ranging from not having many data structures to not having a package manager and thus needing to write a lot more code themselves. If C forced developers to be good at debugging we'd know by now — and I'd see less printf() debugging — and being forced to cobble together more of what you get out of the box with Rust means that those skills are less portable because different programs have different combinations of conventions, macros, and libraries in use. A C developer with a lot of Windows experience is going to have a rougher time debugging a Linux program (repeat for MacOS, iOS, *BSD, etc.) than a Rust developer simply because the limited language set means even basic tasks like text processing follow project-specific conventions.
Rust is more complex than C. It's not a controversial statement.
You're arguing past that, saying that Rust is more ergonomic, or has more built-in functionality, or is more cross-platform, or has one true package manager, etc. All of that may be true but it doesn't make Rust simpler than C.
In any event, if Rust wants to take over the world but disdains "weird architectures" or "dying" hardware, well, we'll see how that plays out for them.
I hope we do get safer software one way or another, so I wish the Rust folks well. That's why I'm pointing out that this is lousy politicking. I'm not trying to hate Rust.
> 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.
I think you're dramatically under-estimating the amount of extra work a C developer has to do, ranging from not having many data structures to not having a package manager and thus needing to write a lot more code themselves. If C forced developers to be good at debugging we'd know by now — and I'd see less printf() debugging — and being forced to cobble together more of what you get out of the box with Rust means that those skills are less portable because different programs have different combinations of conventions, macros, and libraries in use. A C developer with a lot of Windows experience is going to have a rougher time debugging a Linux program (repeat for MacOS, iOS, *BSD, etc.) than a Rust developer simply because the limited language set means even basic tasks like text processing follow project-specific conventions.