If things were to otherwise stay the same, then it would. They won't. Some descendant of "vibe coding" will become the dominant mode within 20 years. Probably a *lot* sooner. Next year wouldn't really surprise me.

Also, Rust is more complex to use than C, so a small program is much better in C. And a large program is probably better in either C++ or Python(with a lot of library calls).

I don't like Rust, so I'm probably not being fair to it, but I struggle to identify a good use case. (Personally, I'd rather use Forth than Rust.)

Note however "will be", not "is". It's not there yet.
Then you have the problem of getting the right standards.
Then you have the problem of getting the right specs.
Then you have the problem of getting the right problem. ...
There's probably an end to this somewhere, but I doubt that it will be in perfection.

Nobody can write safe code. People, can, however, test the code they write, and if there is a comprehensive test suite, fix it so that it works safely. Debugging is mandatory!

Unfortunately auto correct sabotaged your original post. Until this post I was wondering what you meant by "sill working."

If you are hiring a developer your chances of finding one who is not incompetent is vanishingly small. The correct approach is to train them to be competent, and set standards. This should begin with requiring the bug tracker to be emptied out (or decreasing bug count, if the total number is currently overwhelmingly large), and there are plenty of online and in-person resources for training developers to learn how to write secure code.

Security vulnerabilities happen in every language. Anyone who thinks the language will make them safe is an idiot. What I mean is, you are an idiot, cmseagle 1195671.

The problem as I see it is coming up with good standards. We do have standards in some places, for example, SOX requires changing passwords every three months as best practices. But that is probably not actually best practice, so the wrong thing was codified.

How do we get the right things codified is the question.

My take was that he could have stopped it if he wanted to, but the bureaucratic machine was already in motion, and he would have had to put some effort into stopping it. I'm glad we didn't bomb Kyoto but maybe Xi will.

Wow, I hate both sides.

This guy claims that the crime reports just got routed to a different department. Probably not reliable, but neither is an opinion page in NYT

It was easy. I asked, "ChatGPT, are there any security bugs in this code?"

My code is now proven secure, get with the program.

This. Most companies don't follow best practices when it comes to good code (for example, they have a bug tracker that is always growing, never empty). They don't try to write secure code, they don't have trainings in secure code, they don't penalize insecure code (although they should in a lot of cases). That is why most corporate programmers can't write secure code.

History shows that incompetent developers cannot write safe code. There are examples of programmers writing safe code.

People who make excuses for unsafe code are usually crappy developers, and that is what I think of you. You're a crappy developer if you can code at all.

They aren't brittle. I've looked at them. The code is fine, but it uses an older style that is annoying to newbies.

If I were going to rewrite something in Rust, I would look at Firefox, not Coreutils which I would consider a waste of time.

And meanwhile, you keep presenting nothing more than absurd pedantic deflection from the means that LLMs actually use to achieve tasks, trying to mislead people into thinking that they're just disguised probability tables, ignoring the actual consequences of your derailment of the conversation from actual mechanisms to an exponentially-exploding model of the consequences of said actual mechanism, and even in your pedantism, failing to understand the difference between a Markovian state (the physical hardware state) and a Nth-order autoregressive process (the linguistic processing).