Hacker News Reader

Comment by procaryote | Hacker News Reader

The other direction might be more interesting, in case rust drops in popularity in a couple of years, leaving behind a bunch of "let's rewrite in rust" efforts

View on HN

I am not convinced that anyone would take a working rust project and rewrite it in C. I don’t see any good reason to do so.

When rust will lose popularity, it is going to happen eventually, I would bet it’s in favour of a newer and more promising programming language. Not C.

I think Rust has hit critical mass. It's now basically the default choice for something you want to perform well but want to be reasonably secure. For example, uv in the python ecosystem.

Rust is the clear winner of the LLM era. With code generation being so effortless, why would you write in any other language?

i don't use LLMs, but i've heard people complain current LLMs are not good at writing Rust

Current LLMs are not good at writing any language you actually understand, unless you do so much of the work that you might as well have written the whole program yourself.

They're excellent at doing things I'm not an expert at, though! https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect

We should make calculators like this for kids to learn on. Every so often it makes mistakes that you will spot if you could have done the arithmetic yourself and are just saving time. That is where ai code is at right now.

This is exactly why I don't trust LLMs (and therefore why I don't use them). When dealing with something I know about I can see the many mistakes they make - I would have to be a complete fool to trust them to do better on subjects I don't know about.

yeah that narrative was popular last year. You can't go wrong with LLMs on Rust.

Maybe I'm doing it wrong (using a variety of models on GitHub Copilot) but in complex tasks I often find that they give me code that doesn't quite compile (often due to lifetime errors, sometimes other issues)

Try agents like Claude code. My experience was that the initial code was conceptually correct with some type errors on the first pass. It then iterated on compile errors about 6 times, tweaking the code to resolve the issues. Then it compiled and ran correctly.

This was about 500 lines of working rust in about 10 minutes, approximately 25x my pace at writing rust. (I’m a bit of a beginner.)

That narrative is still popular with LLMs themselves. If you ask an LLM whether it can code Rust, it will tell you that it can but not very well.

They're good at web languages, python, and C/C++. As far as I can tell Rust works if you're already good at Rust and you can catch its screwups and strange architecture choices quickly.

The ultimate goal is for LLM replace languages, and directly perform tasks, why bother with Rust when we will be using agentic runtimes?

I feel so safe when my Rust code compiles; it feels like the program will run forever. I'm not sure what you mean by "agentic runtimes," but if they offer the same safety standards as Rust, I wouldn't mind using them.

Beware of too much expectations,

https://edera.dev/stories/tarmageddon

what you sharing is not a rust specific, It's the same for npm and pypy packages.

Rust is native binary + fearless concurrency + memory safe and AI can help you to achieve these targets very fast. That's why Rust is the winner of all the languages, every software needs to be fast, secure and able to run forever.

How is Rust winning on CUDA and Khronos standards?

wait until China releases their open source CUDA on pure rust code.

If you read HN you might get that impression, but that vast majority of software that needs security and good performance is being written in Java.

If you were building a programming language, would you write it in Java or Rust?

I'm not personally a fan of Java, but if I was implementing a compiler, I'd pick a language with GC. There's pretty much no downside to a GC in that context, and it gives you more flexibility when working with graph data structures.

If 'building a programming language' means writing an interpreter or VM, then I can see the attraction of Rust for that case. But writing interpreters and VMs is like 0.0001% of the programming that gets done in the world.

Graal and Truffle make the JVM look attractive, especially for this case!

In those two alone, Java.

There is no reason I would care about borrow checking implementing a compiler, and besides all the tooling, Java also has stuff like ANTRLR and MPS, and naturally Graal is a good playground for compiler backend tooling.

However in general, I would rather look into OCaml, Haskell, F#, Scala.

I wouldn't be surprised if that was closer to the truth. A heck of a lot of boring software runs on the JVM. That said, it's a slightly different niche from command line tools.

Alongside C# in more Microsoft influenced culture shops. :)

new chips will always have a c compiler available long before anything else

I would assume that an LLVM backend is created for new chips and then C is not the only thing getting support. There's very little point in just supporting C in that sense.

That doesn't seem to have been an issue for recent new CPU architectures. RISC-V has excellent Rust support for example.

Not really. Rust still doesn't support Arm SVE or RVV intrinsics.

I suppose so. I'd see that as more of a missing Rust language feature (SIMD support is still immature) rather than a platform support issue though.

Neither does C, the regular ISO C as defined by WG14.

Alongside a much safer C++ compiler.

In 2025 there are hardly single language compiler toolchains being released.

Also if the chip toolchain is based on a GCC or clang fork, there are several frontends to chose from.

Compile speed maybe the only one. But hopefully that keeps becoming less of a difference

Language popularity is cyclical; the hedge is to treat Rust as an implementation detail behind stable, language-agnostic boundaries (protocols, C ABI, WASM) and invest in strong tests/specs. If Rust wanes, migrate piecemeal: keep interfaces, reimplement modules elsewhere, and verify parity with property tests and benchmarks. Multi-agent, agentic LLM workflows can prototype alternatives in parallel, generate FFI/interop shims, and cross-check behavior to de-risk the swap without another “big rewrite.”

That would also help use Rust in platforms that only have a C compiler.

People have used mrustc like that to put rust on a c64. The number of targets that make sense from a word length perspective that aren't already supported by llvm are pretty small I think? You aren't going to compile rust to some fixed point dsp where a long is 48bits. The c anything is likely to generate won't compile in whatever odd not-quite-ansi c compiler the chip maker provides.

That could be interesting. If some new language or tool appears that automatically figures out the correct lifetime and ownership of the resources in your program, people (might be the same people) will call for rewrites from Rust into the new language, as you would no longer have to assign memory ownership manually.

Reply on news.ycombinator.com