Comment by x-yl

10 hours ago

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.

7 comments

x-yl

Reply
gritzko  34 minutes ago

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).

jorvi  9 hours ago

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

apatheticonion  5 hours ago

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