In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust.

They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex<Refcell<` a-la global JS variables for info sharing instead of working out the lifetimes to do it properly. It loves making functions infallible and then panic-ing within them and certainly I wouldn't use them for unsafe at all - they hallucinate safety comments which are in fact, totally unsound.

Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .clone() and an Arc<Mutex<>> means they will spend minutes 'thinking' about basic lifetime issues until I step in and add the missing `move` in a closure.

same experience. any good claude skills to ease the pain?

LLMs generally write poor quality anything. It'll [usually] work, but it'll need massive refactoring to get in a maintainable and efficient state.

I've actually found Opus 4.7 to write decent Django / Python code.

this was true a year ago but not so much anymore. You still have to supervise the agents, but they can write maintainable code if you keep an eye on it.

Maybe true 6 months ago, but now it's better than any Rust Dev, as long as you guide it and not just let it rip on a full service/app unsupervised.

It's better than any Rust dev... as long as you guide it

What?

You gotta know how to write Rust (and general software arch) first. LLMs + Rust have been great for me.

"Write an SQL Repository with this interface"

Sweet - no need for SQLc or an ORM

That is interesting. I make LLMs write C with the general hope that a simpler language they can manage well. That is not entirely true, though. They reason about C fluently indeed. The problem is, Claude pumps lots of bad C into the codebase if left unattended for 5 min. So, I need some clean-up passes afterwards to get to some acceptable quality level (both by LLMs and my own eyes). At which point, Claude sees the problem clearly, for some mysterious reason. Also, I use a C dialect heavly influenced by Go (slices, generics, no smart tricks, virtually no malloc).

> general hope that a simpler language they can manage well

It's the opposite; a language with lots of guardrails allows the AI to write better code especially as it is able to use the compiler and linter to guide it through the process. It's why OpenAI for example was able to disprove some recent theorem recently, due to the LLM converting its thoughts into a formal language theorem prover to then check its work.

> if left unattended for 5 min.

Is THAT how people use AI? I thought _I_ was vibe coding by telling it to write one function at a time and making sure I understand every line it outputs.

"Vibe coding" is a term that means "Prompt the LLM with a request for a project and wait for it to finish". If you're reading and understanding anything it made, that's not vibe coding, that's agentic development.

We’ve developed incredibly strict and comprehensive clippy rules and found that to drastically improve the quality of the code as the LLM now should pass all clippy checks. You can add a clippy skill as well to attempt to turn “should” into “must.”

For me the bottleneck now is reading/reviewing code, not writing code. As you said, AI makes it way easier to write, but do you not review the code? And isn't a verbose, cryptic language with lots of nitty gritty memory management not harder to read/review?

I'm not sold on Rust being a great language to use with AI unless the reason to use it is a lot more than just Rust being fashionable.

IMO neither Go nor Rust are great for reading/reviewing code.

Go is too verbose and the type system isn't expressive enough. Rust code is littered with little memory management details and it requires tons of third party libraries.

I think coding agents will eventually be able to get the low level details right on their own. Reviewers should be able to focus on architecture, design and logic mistakes.

I also think we need a high level formal specification language to tell agents what we expect them to do.

> I also think we need a high level formal specification language to tell agents what we expect them to do.

Let’s make that specification Turing complete while at it.

Jokes aside, IMO it will be a good natural progression. Specify the problem statement in LLM specification, generate the code in Go/Rust whatever is the language of your choice and review the generated code to make sure it adheres to the architecture/design principles that you have set.

It absolutely should be Turing complete. I want to formally specify some constraints/invariants that any generated code has to meet, like very high level test cases.

It doesn't have to be a new language. I'm sure some existing language can be used to create a DSL that serves this purpose.

It can obviously never be complete. Some parts of the spec will always have to be natural language if we want to make the best use of LLMs.

Maybe we can have Large Logic Models instead, and they could have formalized keywords with rigid meanings? Like IF, WHILE and FOREACH maybe. Or even ASYNC if you want to be modern about it.

I do think that AI models should get better at logic. But if code generators are supposed to be tools, we have to tell them what to do. I'm not sure what combination of languages is best for that purpose.

It would be so much easier if we could precisely specify what we wanted, without all the double meanings, slang and general ambiguity that comes from using a natural language.

If only there was an entire class of well-studied languages which don't have any such ambiguity. They'd be perfect for programming LLMs! We could call them "programming languages" perhaps.

But what we want is a lot of ambiguity on the implementation side and some targeted ambiguity on the specification side where appropriate.

In my experience, Rust is only mildly unpleasant to review, if only because the GitHub PR review interface is not an IDE. It can be hard to tell why .as_ref()s and whatnot had to be used without being able to hover over a variable to see its type. This is probably because of the language's preference for type inference, though personally I would rather that than having to skim over explicit types.

Compared to Rust, Go as a language requires a lot more effort to review. You have to be on the lookout for basic gotchas like not checking if a pointer is nil, placing `defer` in the wrong place, using a result when err isn't nil, and so on. Plus, diffs are messier because unused variables are a compilation error, and _, err := can change into _, err = solely due to new lines above.

And := not being = can really matter for variable shadowing.

Absolutely insane syntax choice in a language where everything returns 2 values. At least do var:, err: =

It's the same logic for human and for AI code: In Rust the compiler catches many bugs so you don't have to.

If the LLM gives you safe code you know there are entire classes of things you don't have to review for.

That said, I agree with you. My experience is that LLMs are great if you are highly competent in the domain in which you let them work. And it's probably easier to be competent in Go than in Rust.

Safe? No compiler is going to catch badly designed code, or intentionally backdoored code. Memory leaks as well. Compilers are the ground floor of validation and the least of your problems with AI generated code.

A mythical compiler might catch unsafe code

Yes? Does that contradict anything I said?

If the program design follows the principle of making illegal states unrepresentable (credit to Yaron Minsky), the compiler can catch much, much more than most people realize.

The process of designing a program like that itself catches a lot of "badly designed code". And such a design also naturally exposes many kinds of intentional backdoors, because security properties can quite easily be statically checked. For example, IDORs can be made literally impossible in such a design.

In discussions like this, I'm reminded of the William Gibson quote, "the future is already here, it's just unevenly distributed."

I found it's the opposite. Thanks to LLM's whole classes of problems otherwise solved by using Rust are gone. It's now more important that the generated code is easy to read.

Relative to Go? I'm pretty sure your Go code won't be faster if you used LLMs. If you need that, Rust is still preferred.

Relative to C/C++? That'll be very interesting. Do you have some evidence that LLMs can create memory-safe code in C/C++? It'll be truly amazing if true, but given that they apparently struggle to create/maintain big codebases in already-memory-safe languages I seriously doubt it.

Yes, generated C++ is memory-safe. Also there is much more C/C++ code out there LLM's got trained on showing in the quality.

Reading the code? Who has the time.

Aah, I am sure the chickens of vibe coded origin, will never come to roost.

Time isn't the constraint here, but ability. Someone complaining about how hard Rust is to write is probably not capable of reviewing Rust code very well.

The usual reaction or opinion from e.g. good C++ programmers switching to Rust is that the added guardrails and expressivity are great and make things easier.

I find it easier to review Rust (but Go too) than to write it.

The build time and space for rust is awful for fast iteration e.g change a thing, verify.

The benefit is if you lean heavily on types then successful compilation is a massive indicator in the feedback loop. Using stop hooks to ensure successful compilation after every iteration is a game changer. Go also has compilation of course but because the type system is so much more robust in Rust the compilation guarantees so much more about the behaviour of your program. You end up just code reviewing the shape and flow of data.

Code compiling is really the lowest bar of code validation, and doesn't say much of anything of the code running correctly. AI will pump out the most convoluted, over engineered, and at the same time sloppy code if you let it - and it will all compile fine.

Yes, but all else being equal it is a higher bar in Rust than in Go. There are fewer things left for the human to check after a clean build+lint in Rust than in Go. The issue of over-engineered AI output is orthogonal to that.

Overengineering and convoluted code stand out when reading. The hard part are the subtle errors. And the Rust compiler helps you out a lot more here

It's the lowest bar and that's precisely why you want it to be as high as possible.

For me, one of the bigger complaints is that Rust isn't pedantic enough. Panic free Rust isn't taken seriously enough as an idea.

I wish it would catch even more things, since it works so well.

Well, a good type system like Rust's lets you make impossible states impossible to enter/represent by the system.

Writing code so that impossible states are impossible is one of the hardest parts of software, so a good type system means that the code compiling means that the software is validated to be unable to represent certain states which is a very high bar of validation.

I suppose in your mind you were thinking of more trivial errors like typos, accessing variables that aren't available in scope, and such.

This is the main reason I use Rust over Go these days. The simplicity of Go was great for when I had to hold everything in my head and write everything myself. Rust makes more sense to me in the LLM era where I can offload more modeling/assumptions/invariants to the type system without having to be a Rust veteran.

The pinned invariants in my plan/spec become first-class invariants in the type system. It's great.

It is of course the lowest bar. The main point is that the lowest bar in Rust is already a really a high bar compared to go lowest bar.

I find Go harder to review than Rust.

The verbose error handling diluting the interesting parts is one thing, but the main issue is the weak type system. Having to read the callee's code to check if it deviates from `res xor err`, or if it mutates its arguments. Figuring out which interface that `func (o *Obj) ()` is implementing, if any. Dealing with documentation that is a wall of 100 disappointing oneliners all repeating the function name.

Rust is information-dense and takes longer to master, but it's not inherently cryptic, there's a finite amount of things to know. Memory management sometimes take a bit of thought to write, but it's straightforward to review, you can trust it's correct if it compiles, you just keep an eye out for optimizations.

I don't see the difference in exploring an dense custom type system versus a flatter one. Both force you to look things up when you don't know about them.

In my opinion these problems originate in architectural style. Much of the open source written today is designed to impress the audience instead of focusing on the problem.

Go was never about being easy to write (thought it is), but it was always about being easy to read and it is, by far, the easiest language to read that I've ever used (and throughout the decades, I went through Basic, Pascal, C, Java, JavaScript, C#, TypeScript, Ruby and Python). That becomes even more important if you are not writing the code yourself...

it's too verbose, yet not explicit.

you need to know the conventions to spot what's not there (did you miss the error handling? or the magic comment for the whatever codegen serializer? c'est la vie!)

edit: just a few comments below an even better description of what I'm trying to convey: https://news.ycombinator.com/item?id=48264853

Disagree, if you miss the error handling the code won’t compile (unless you return _, which should be easy to spot)

The magic comment stuff is very much “do it once” and it’s done (for example if using go generate).

> The struggle with rust was writing it, go was made so it was easy to write for mid level engineers.

In practice, anything that makes it easier for humans to program also makes it easier for LLMs to program.

You also wont typically learn that the LLM is close to the limits of understanding your code base until after it has blown past it's own capabilities, leaving you with a mountain of code that you are not skilled enough to fix.

Java, C# are good choices as they tend to enforce a certain structure. Go, good because it's very readable even if you dont know the language.

C++, Rust are poor choices unless you are already a senior in that language.

The value prop of Go in not on writing, but in reading and comprehension by people different from the autor(s). For systems expected to last some years, this translates in reduced total cost of maintenance over the life of the system (in my experience typically 80% or more of the total cost) and facilitating traspassing maintenance to diferent people than the authors. In use cases where Go has "good enough" performance, for backend systems with business logic and small amount of "bare metal" programming, I recommend Go to teams instead of Rust. When extreme performance and reduced memory footprint is more important than the other properties, Rust is better than Go.

>Now that we have agentic coding I just write everything in Rust and couldn’t be happier. The struggle with rust was writing it, go was made so it was easy to write for mid level engineers. Now that we have agentic coding I’m not sure Go’s value prop holds up anymore

Agents seem to have a better time with Go. Humans need to review the agents outputs and in general they have an easier time to do it with Go.

Go is really easy to read and write, even if Go's philosophy means that some of that feels clunky because it's less featureful than other languages. It makes up for it with a comprehensive stlib that makes it trivial to build services with few to no third party dependencies.

I don't think the value prop has changed at all there. One day the AI gravy train will stop and people who used AI to punch above their weight will no longer be able to debug the stuff they built unless they put in the hard work of learning the language.

Nothing to worry about with Go in that respect because of how much it's been designed to be simple. Even the annoying err/nil checks you need to do all the time are in service of that simplicity. It gets old fast but it leaves nothing to the imagination.