Comment by mike_hearn | Hacker News Reader

Comment by mike_hearn | Hacker News Reader

Parent Full thread

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!

Reply on news.ycombinator.com