Technically in a few years LLMs may be good enough to ensure that even C code is bug proof by making sure every unchecked write is checked. Every write to a buffer has some constraint. That or it just ports things to rs
w.r.t the first point, so ideally you wouldn't want to do that because it'd incur a heavy runtime performance. Rust's memory analysis allows eliminating those kinds of memory bugs without having to check writes at runtime.
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.
Rust definitively became a cult.
Humanity runs on C and C runs on devices that Rust devs can't even imagine they exist, but they want humanity to bend the knee to the god Rust.
This madness needs to stop.
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.
Rust is cool. A great idea, if a little hard to wrap a grug-brain like mine around (I've tried, and will try again, I'm sure)
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
So to clarify, the crusade to rewrite things in Rust is not my fight. To be honest, I'm more a third party watching from the sidelines. There seems to be big institutional interest in replacing C with Rust. Not for ideological reasons. Just for plain economic ones. Rust code is breaking industry standards of memory safety/bug density/review time. I link it in the article, but for example, darpa has a recent big grant program, TRACTOR: Translating All C to Rust (https://www.darpa.mil/research/programs/translating-all-c-to...).
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.
If it is your article that makes the title clickbait.
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.
Technically in a few years LLMs may be good enough to ensure that even C code is bug proof by making sure every unchecked write is checked. Every write to a buffer has some constraint. That or it just ports things to rs
w.r.t the first point, so ideally you wouldn't want to do that because it'd incur a heavy runtime performance. Rust's memory analysis allows eliminating those kinds of memory bugs without having to check writes at runtime.
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.
Rust definitively became a cult. Humanity runs on C and C runs on devices that Rust devs can't even imagine they exist, but they want humanity to bend the knee to the god Rust. This madness needs to stop.
If it has become a cult, it's become a cult that has infiltrated so far as DARPA - see their TRACTOR program (https://www.darpa.mil/research/programs/translating-all-c-to...)
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.
Nobody is questioning the results, just the evangelism.
Rust is cool. A great idea, if a little hard to wrap a grug-brain like mine around (I've tried, and will try again, I'm sure)
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
So to clarify, the crusade to rewrite things in Rust is not my fight. To be honest, I'm more a third party watching from the sidelines. There seems to be big institutional interest in replacing C with Rust. Not for ideological reasons. Just for plain economic ones. Rust code is breaking industry standards of memory safety/bug density/review time. I link it in the article, but for example, darpa has a recent big grant program, TRACTOR: Translating All C to Rust (https://www.darpa.mil/research/programs/translating-all-c-to...).
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.
If it is your article that makes the title clickbait.
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.