> Rust doesn't prevent programs from having logic errors.

Like everything around Rust, this has been discussed ad nauseam.

Preventing memory safety bugs has a meaningful impact in reducing CVEs, even if it has no impact on logic bugs. (Which: I think you could argue the flexible and expressive type system helps with. But for the sake of this argument, let's say it provides no benefits.)

▲ zdragnar 17 hours ago | parent [-]

It isn't like rust is the only language with memory safety; plenty of high level languages don't let you fiddle with memory bits in a way that would be unsafe. The tradeoff is that they typically come with garbage collectors.

If the only concern is "can an LLM write code in this language without memory errors" then there's plenty of reasons to choose a language other than Rust.

▲ nialv7 17 hours ago | parent | next [-]

But the author isn't saying we should program in any of these memory safe languages. The author is saying why don't we vibe code in C, or even assembly.

▲ zdragnar 16 hours ago | parent [-]

This thread moved the conversation away from the posted article quite a few messages ago.

First, Rust has lots of checks that C and assembly don't, and AI benefits from those checks. Then, a post about those checks are related to memory safety, not logic errors. Then, a post about whether that's a helpful comment. Finally, me pointing out that checks regarding types and memory errors aren't unique to Rust and there's tons of languages that could benefit.

Since you want to bring it back to the original article, here's a quote from the author:

    Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal. To say nothing of Haskell, or OCaml, or even Python. All of these languages, after all, are for people to read, and only incidentally for machines to execute.

It would seem that the author fundamentally misunderstand significant reasons for many of the languages he mentions to be the way that they are.

▲

9rx 15 hours ago | parent [-]

> Rust has lots of checks that C and assembly don't, and AI benefits from those checks.

Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation.

But if you don't find the need for those checks in order to consider Rust, why not C or even assembly instead?

	▲	nylonstrung 7 hours ago \| parent [-]
		Fil-C is way too new for LLMs to understand it and not just hallucinate back into normal C

▲ Maxatar 15 hours ago | parent | prev [-]

The trade-off is intended to make it easier for people to write software. Garbage collected languages make it easier for people to write memory safe code at the expense of performance, significantly greater memory usage, and heavy dependencies/runtimes.

These trade-offs are wholly unnecessary if the LLM writes the software in Rust, assuming that in principle the LLM is able to do so.