My interpretation of his stance so far was "I'm not going to block Rust support in the kernel and I'm not fundamentally against it". I think that's different from backing Rust - although feel free to correct me with a link to his email communications for example that demonstrates otherwise.
> And yet, C/C++ programs segfault all the time. Memory corruption vulnerabilities are some of the most severe and common ones.
There's a good chance that the kernel you are currently using was written in C/C++ and is really quite reliable.
> There was something about Google adopting Rust on Android precisely because of this — in case you want to find it.
Let's see how it goes for them, it's a good experiment for whether Rust really is suitable for kernel development. I know there is some concerns about using Rust for kernel drivers as a lot of speed-up comes from making 'unsafe' assumptions, i.e. seeing io_uring that should enable ultra fast networking. I suspect Android has other significant problems that will block this though.
> I've been a C (Kernel) programmer in the past. And I've quit precisely because it took too much of my time to debug things that a good language should normally detect for you.
I've done some small kernel programming in the past in both C and assembly, this was for safety critical code that (to my knowledge) is still in use today and is required to run indefinitely without software updates. On top of static code analysis, regression testing, unit testing, black box testing (dedicated team) - I would also purposely try to force all meaningful code paths during initial development to make sure that my assumptions about memory are correct.
> Now, my main languages are Rust and Haskell, and the compiler helps me eliminate a huge class of bugs. If it compiles, most of the time it works correctly.
These days I am mostly developing in C/C++ (fast and efficient), Java (reliable cross-platform behaviour), Python (haven't really thought through the idea yet or ML) and Bash (connect several parts together). I rarely run into issues, my C/C++ server based programs run for over a year, only being restarted to pull in new features.
> What should I be looking for in [1]?
Memory, or speed. Whichever C is optimized for it tends to win in. If it doesn't, it can be re-written to do so.
> And what do you mean here? "Theoretically", you could implement every possible C program in Assembly, but that's hardly an argument against C.
It's to say that C should be at least as fast/memory efficient as Rust, in the same way that assembly should be at least as fast/memory efficient as C. Let's not pretend there is no value to speed and memory, otherwise why are we bothering compiling Rust to binary and not just running it on the JVM.
> We should be thinking here in terms of things that a programmer normally would implement in reasonable amount of time. A knowledgeable Rust programmer is by orders of magnitude more productive than a C programmer with the same experience.
In C, likely. In C++? Maybe about the same. One thing Rust has is packaging, but this is also creating massive package chains which have big stability/security issues.
> The argument for C against Rust just doesn't stand a chance if you remember C's undefined behavior. C is full of it. Can you list all the conditions when it can occur in C?
I don't need to know the entire of the C language to use it effectively. The undefined cases are quite rare unless you go looking for them. There is a standard subset of features I use, and I look up the others as and when I need them. For example it is entirely possible to use Java 11+ by just knowing Java 1 and looking up some small changes to the standard libraries since.
