Hacker News Reader

Comment by maxbond | Hacker News Reader

1000x yes. Rust is not a One True Language, there exists no One True Language. Rust made some improvements over previous languages (many of which were ported over from previous languages that demonstrated the value but weren't break out successes) and serendipitously those improvements added up to something that was really significant and unlocked interesting and useful capabilities. I'm never going back to how my workflows were before I learned Rust (though I still write in other languages everyday).

But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.

C, Python, Java, are just a couple random languages that were/are similarly influential. (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)

View on HN

The weird thing about this is many core Rust people agree that Rust is not the best language that could possibly ever be, even evaluated by the core principles of Rust (that is: no UB, no mutable aliasing, no memory bugs).

And if we move outside of Rust's memory model, some people have raised issues with the inconsistent syntax, and the module-based compilation model which makes compilers inherently slow, as you have to parse the whole module every time.

So there's room for improvement, and people are already working on putting ideas into practice, and some of these people who came from the Rust ecosystem itself.

And if you happen to disagree with Rust's core goals (or just place less emphasis on them), then it's obviously not the perfect language.

> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.

That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.

Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.

Fil-C is actually not very low-level efficient, Golang probably has better efficiency (being built from the ground up for lightweight concurrent GC) and a hypothetical support within Rust for "pluggable" GC heaps might be even more clearly preferable.

I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC), as well as the program will simply crash on arbitrary memory reinterpretation, use-after-free, and reading uninitialized memory. This is certainly better than it continuing, but certainly not as good as it could be.

CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.

In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.

So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).

* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.

Really what I'm getting at is that people are not done innovating on C ergonomics and safety and that there is potential there. Not that there is a new shivel-ready paradigm shift that has arrived to C. I'm only saying that that may happen and that it is more likely than most people credit.

> I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC)

Yeah this is where I stand with it. Fil-C seems to be the worst of all worlds. It combines the performance of an immature GC language, with the primitive syntax and ecosystem of C. (Eg nullability, void*, no generics, no collection types, a bad standard library, header files, no good build system, bad cross-OS portability, BYO strings, etc).

I don't choose C for its wonderful syntax. I choose it because its small, light and performant. If I was happy to use a garbage collector, I'd much prefer to go all the way and grab Typescript, C# or Go.

The only use case I can see for Fil-C is running legacy code that you can't be bothered porting to a better language.

Don't forget the compatibility issues: Fil-C isn't really usable if you mix C with other languages in the process.

It's especially problematic to have multiple different garbage collectors; so given the desire to reuse libraries across language boundaries, there's still a strong demand for Yolo-C, C++ or Rust.

I think Rust has a big flaw to overcome in the age of LLMs: slow compilation.

If they can't fix this, a language with similar guarantees, even syntax, but fast compilation is bound to succeed in niches where Rust is desireable.

Iteration speed is a big bottleneck in agentic workflows. Well, any workflow.

If your LLM can output 10-100x the LOC output, and it's equally good at all languages, and you're not bound to an existing language choice or ecosystem, why not choose Rust?

Rust code will be faster, safer, and easier to ameliorate bugs in.

Rust seems like the best language to serialize business logic to now that LLMs are so good at it.

If the LLM makes a mistake in Javascript or Python, you literally won't know until runtime. With Rust, you'll know immediately and have really good compiler recommendations for fixes.

I think Rust is the best LLM language. I am somewhat biased: I've written Rust code for ten years, and I'm having a blast with Claude Code writing it for me instead now. But I've also used so many other tools and languages - enough to say that Rust has some unique advantages here. And also that Claude does a fantastic job emitting Rust.

LLMs emitting Python feels like building with clay. LLMs emitting Rust feels like building well-engineered steel skyscrapers.

I do choose Rust. For now. I write Rust everyday. I'm generating Rust at this moment.

But when I learn a better language I will adopt it.

I'm also having a really good time having LLMs write code in Rust. In Typescript they tend to abuse `any` or just cast stuff around, bypassing the type system at every corner. In Rust they seem to take compiler errors to heart and things tend to work well.

You might also have success asking your agent to run `eslint` at the end of every subtask and instruct it to always address lint errors, even if they are preexisting. I agree with your diagnosis; there's "implicit prompting" in Rust being more strongly typed and the agent "knowing" that going in but we can compensate with explicit prompting. (You do also have to tell it to actually fix the lints, I find, or it will conclude they aren't relevant.)

> LLMs emitting Rust feels like building well-engineered steel skyscrapers

Oh the irony.

Good thing that real engineers cannot build their skyscrapes with LLMs.

> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change

I agree, and I'm interested to see what it is in the age of LLMs or similar future tools. I suspect a future phase change might be towards disregarding how easy it is for humans to work with the code and instead focus on provability, testing, perhaps combined with token efficiency.

Maybe Lean combined with Rust shrunk down to something that is very compiler friendly. Imagine if you could specify what you need in high level language and instead of getting back "vibe code", you get back proven correct code, because that's the only kind of code that will successfully compile.

Sir/Madam/Sovereign... did you hear about Prolog? ;)

This isn't the first time someone has said that to me, so I really ought to make time to learn it.

> (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)

Lisp. Which coincidentally solved memory management over a decade before C was created.

I also think ALGOL was more influential than COBOL, but measuring influence can be tricky.

Reply on news.ycombinator.com