w.r.t the second point, I talk a bit about that in the article itself -- the fundamental problem right now is that there's no real formal way of even stating what it means to correctly translate a program from C to Rust. We could maybe have a smart LLM that translates things to Rust, but would you trust it without tests? or ideally a proof of correctness? what properties should we test? etc.
BUT
There are plenty of programs written in C which require no rewrite, do what they're supposed to, and have been doing what they're supposed to for decades. Yes, it's possible to write C code with "heisenbugs" and it's harder to do so in Rust - and that's a good thing. But if it works, it doesn't need fixing, so calling C a "stain" is a little over-dramatic. Continue with the ports, continue to use Rust - especially now, as the pace of development is (imo) faster than 2 decades ago, and the one thing that speed almost guarantees is mistakes - having a compiler catch those for you (especially if you can understand the output!) is great. Requiring total conversion of all C projects to Rust is... cultish? I guess to be expected - the author has had pain in the past, alleviated by Rust, and so they will spread the good word about their savior, but I see a lot of conversation in this realm which is all-or-nothing (both ways - C or Rust), and I think those arguments miss the points:
1. Reliability - use what's reliable to write new stuff; if old stuff is already reliable, and simple enough to check, focus elsewhere - there's too much to rebuild it all, so focus on what actually needs attention 2. Functionality - use what works (program-wise). Going "ew, written in C" gets you nowhere. On this line, I'd really appreciate an "ez mode" for Rust where errors are displayed in language that someone not living in the Rust world for months can grok. I'm not alone here. 3. Kindness - there's no need to go on crusades in the name of a language. All software is flawed in some way, including that golden turd you wrote in Rust. Got no bugs? Someone will be missing a feature. Got heaps of features? Someone has a bug. This world would be a lot nicer to live in if people could just be kind. Instead of "C is trash", perhaps "We got a lot of shit done in C, but Rust helps us to make better software, so let's go!".
Calling one of the greatest inventions in programming history a "stain" is egotistical at best, shining hubris at worst (seriously! without it, no linux, no GNU, and heaps of other things that just don't get made, or are made in something like FORTRAN or COBOL).
Also, shut up and eat your vegetables, and get off my lawn. :D
My article was more a commentary aimed at the efforts towards doing that. In some sense arguing that there are some foundational formal deficiencies currently that mean that it's not even clear what success would be. I guess I don't really take a position on the value of rewriting things into Rust, aside from adopting the views of these existing programs as some prelude.
As others have said, it is ridiculous to suggest the code which controls Christmas tree lights must be written in Rust. In your example it would be easier to follow the machine code generated (which only has "if' and "go to") in C than in Rust.
I think couching the success and excitement around rust to ideology or a "cult" as you say is somewhat digging your head into the sand. There are concrete facts and results. Rust is empirically producing levels of memory safety that humanity did not think was possible with software at scale. This is truly groundbreaking.
