Comment by onlyrealcuzzo | Hacker News Reader

Comment by onlyrealcuzzo | Hacker News Reader

Parent Full thread

> whenever I use AI for Rust, it makes an insane amount of lifetime errors.

What model are you using, and what frameworks are you using?

This is not a hard problem for LLMs to solve.

Rust is nearly the perfect language for LLMs.

It's exceptionally expressive, and it forbids entirely the most common globally complex bugs that LLMs simply do not (and won't for some time) have the context window size to properly reason about.

Dynamically typed languages are a disaster for LLMs because they allow global complexity WRT to implicit type contracts (that they do not and cannot be relied on to withhold).

If you're going to add types, as someone pointed out earlier, why are you even telling an LLM to write Python anyways?

Rust is barely harder to read than Python with types. It's highly expressive.

You have the `&mut` which seems alien, verbose (safe) concurrency, and lifetimes - which - if you're vibe coding... you don't really need to understand that thoroughly.

You want an LLM to write code in a language where "if it complies, it works" - because... let me tell you, if you vibe code in a language where errors are caught at runtime instead of compile time... It will definitely NOT work.

It's not nearly the perfect language for LLMs and Rust is dramatically harder to read and reason about than Python with types. Other options work better for nearly all apps. I found Kotlin works well:

- Garbage collected so no reasoning tokens or dev cycles are wasted on manual memory management. You say if you're vibe coding you can ignore lifetimes, but in response to a post that says AI can't do a good job and constantly uses escape hatches that lose the benefits of Rust (and can easily make it worse, copying data all over the place is terrible for performance).

- Very fast iteration speed due to JIT, a fast compiler and ability to use precompiled libraries. Rust is slow to compile.

- High level code that reads nearly like English.

- Semantically compatible with Java and Java libs, so lots of code in the training set.

- Unit tests are in separate files from sources. Rust intermixes them, bloating the context window with tests that may not be relevant to the current task.

Then your domain problem you’re trying to solve doesn’t benefit from Rust.

Sounds like your work doesn’t need Rust and that’s ok.

But don’t generalize.

Unless you're writing kernels, or high integrity systems with memory allocation constrains there is very little reason to use a language like Rust.

Everything that people find great on Rust with exception of the borrow checker, can be found in any compiled language from ML linage. And even that is fading away as they introduce a mix of linear types, dependent types, effects and formal logic.

Rust has uses you haven't mentioned. For example, each compiled language from the ML lineage (and almost every language period) has its own runtime, particularly, its own assumptions and contracts about heap-allocated storage. In contrast, Rust famously does not need a runtime library -- and it is low-level enough that it can usually (with enough cognitive effort by programmers) interface with an arbitrary foreign runtime library -- so when the goal of the code to be written is to interface with code in a compiled language from the ML lineage, you usually have only 2 memory-safe options, namely, the same language as the code-to-be-interfaced-with and Rust.

The situation is a little more complicated than what I just wrote because two programs written in different ML-style languages could communicate via inter-process communication. But I don't see that. (Maybe my experience is not broad enough?) What I see is, e.g., Python libraries written in C and C++ (and Fortran, which is also not memory-safe) for performance reasons where the only memory-safe language that could have been used instead is Rust.

From my point of view those uses are misplaced, hence why I not referred them.

Likewise those Python program should have use a dynamic managed compiled language, like Common Lisp or Julia, which was originally designed exactly to avoid that.

Maybe one day replaced by Mojo, if they get lucky with it.

Too many devs see a specific language as their solution for everything, and when it doesn't fit we end up in such sandwiches.

> high integrity systems with memory allocation constrains

I agree. I also find that a lot of software should have this mindset anyways so Rust is a great fit for that domain. Anything that others depend on should be high integrity and memory efficient.

Not to mention the ecosystem is very wide in Rust. Other ML languages may not have what one needs.

Write a 250k LOC compiler in Python and then get back to me how well LLMs write in Python...

Sure if you want to vibe code a TODO app where it's literally just copying and pasting one it's already seen 10,000 times before, it can do it in Python.

I didn't say it's better to use Python!

This is likely a fully LLM-generated reply.

Reply on news.ycombinator.com