Rust's compile-time checks are actually a nice set of guardrails for LLMs.

Nobody who works with LLM generated code believes that LLMs produce fault-free code.

Yes, languages with very strong type systems like Rust are incredible when paired with an LLM. Just like chat bots have a calculator as a "tool" because they are not the best at calculation themselves, they need a type system to deterministically validate the safety and cohesion of the code they generate.

Its languages like C that you have to watch out for, because the LLM will gladly say "this is safe!" when its not.

The Rust ecosystem and build tools are much easier to use than C. The value of a language isn't just syntax.

LLMs are great at C, probably because C is historically the most popular language in the world, by far. It only declined slightly very recently. But there's insane amount of code written in it.

But are they "no UB in the code" great? For my use, Opus is absolutely good enough at Rust

You don't need to rely on UB in C code either.

Sure. But any nontrivial C codebase will have UB regardless of your intentions. This has been proven time and time again.

'rewrite in C, make sure there are no memory leaks'. You first.

Why is that less realistic than saying 'rewrite in rust, make sure there are no memory leaks'?

My point, which I should have been clearer with, is that we aren't at a state where you can just one shot a rewrite of a complex application into another language and expect some sort of free savings. Once we are at that state, and it's good enough to pull it off, why wouldn't the AI be able to pull it off in C as well?

You don't have to trust the AI to do it with Rust, you just have to ensure certain conventions are followed and you can formally prove you're 'safe' from certain classes of issue, no AI magic dice-roll.

A lot of people are very excited by the idea that now language capabilities (and almost every other technical nuance) somehow don't matter but much like gravity they will continue to assert themselves whether you believe in them or not.

So far humans have proven unable to write large apps in C without those issues, given their work is the training basis for LLMs this creates two problems, one being that they don't 'know' what a safe app looks like either and any humans reviewing the outputted code will be unable to validate that either.

Documentation and testing used to be mildly important, you better have them, but the quality of the tests didn't matter as much, since you have to get the implementation right, no matter how good or bad your tests are.

Now that the work is delegated to an LLM, the test and documentation quality ultimately decides the quality of the product.

Since you as the programmer no longer have to deal with the language's annoyances directly and force the LLM to perform the drudgery for you, you can build a language that makes a trade off between drudgery and quality and receive a software quality upgrade essentially for free.

LLMs are really good at producing tokens faster than developers, so make those tokens count.

There are classes of bug that are easy to write in C that are impossible to express in Rust.

    let foo = [1, 2, 3];
    unsafe {
        *foo.get_unchecked_mut(4) = 5;
    }

Not sure why Rust evangelists always seem to ignore that unsafe exists.

Hmmm... where could the oob access possibly be I can't tell

Easy to spot in a contrived example is not:

> impossible to express in Rust

I’m not going to argue with Rust folks who misrepresent the language.

You can prevent unsafe from being used in a repo with linter rules.

> if the AI can just write really good code in C that doesn't exhibit any of the issues that rust protects you from?

"if"

If it could you wouldn't need to use Rust. It can't, qed.

AI can produce code that is about 70% as good as median quality code found on the internet.

I would not describe median quality C code as free from these issues

Pain is an important signal that tells you something is going wrong, before it goes wrong really badly.

Rust gives you a lot of pain (= useful signals), before damage occurs.

Now imagine you build a reinforcement learning harness around Rust and C. Which is better for reinforcement learning? Impossible to detect failures in the final product or loud and annoying compiler errors that force you to address them?

Because it can't?

Based on a FIDO2 spec I used it to write a reasonably compliant security token implementation that runs on top of Linux USB gadget subsystem (xcept for attestation, because that's completely useless anyway). It also extracted tests from an messy proprietary electron based compliance testsuite that FIDO alliance uses and rewrote them in clean and much more understandable C without a shitton of dependencies that electron mess uses. Without any dependencies but openssl libcrypto, for that matter.

In like 4 hours. (and most of that was me copy pasting things around to feed it reasonable chunks of information, feature by feature)

It also wrote a real-time passive DTLS-SRTP decryptor in C in like 1 hour total based on just the DTLS-SRTP RFC and a sample code of how I write suckless things in C.

I mean people can believe whatever they want. But I believe LLMs can write a reasonably fine C.

I believe that coding LLMs are particularly nice for people who are into C and suckless.