Rust contains the ability to do everything that C can, if you use `unsafe`. And a file-by-file rewrite in Rust from another language usually involves keeping the ABI and API between files very C-like (and unsafe). In practice this means that the result of a first pass this way has all the memory safety of C code, but with worse readability because Rust makes unsafe things less ergonomic.

To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.

I don't think this latter stage has actually happened with Bun's codebase. The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).

> To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.

You can use deterministic linting for `unsafe` usage, have agents target `unsafe`, etc. It's pretty easy. You can even run `miri` against the code and give that as a tool for LLM feedback. I've done this all before and it works fine.

> The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).

I'm unconvinced that this is true. How could you tell? You only know about the rust bugs because rust makes them grep'able/ trivial to verify, there's no way of knowing which bugs existed in zig that didn't translate. Regardless, the problem is now trivial to understand in Rust and start to target.

> one that an unsupervised LLM rewrite is probably not even going to attempt.

Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).

An LLM definitely can do that work, but LLMs have a tendency to follow the path of least resistance unless you force them to do things properly and carefully supervise them.

> LLMs have a tendency to follow the path of least resistance

That's a really strong motivation for the Rust port. It's literally impossible to take a path not leading to an unacceptable outcome because the Rust compiler fails the compile if code no longer marked "unsafe" is still actually unsafe, and the tests fail if the implementation is incorrect. The compiler actively helps to force the LLM to do things properly.

…only if you actually force the LLM not to use `unsafe` somehow! And one must remember that `unsafe` can have all sorts of non-local effects. One way to be maliciously compliant (or in the LLM's case, I guess it's more incompetence than malice) is to make a “safe” function that does an `unsafe` operation for you, and then replace every usage of that unsafe operation with your “safe” function. You can remove hundreds of unsafe blocks that way without any improvement in safety.

Yeah this is going out of scope now. The in-scope safe/unsafe is that which is specifically recognized by the Rust compiler (literal greppable keyword). With that and the tests weighing I'd say it's pretty difficult to be incompetent, as the correct path becomes the easy path. Even if the LLM were to somehow go the maliciously compliant route I'm thinking it'd burn so many beyond-expected tokens trying to get around both compiler and tests that it'd be caught.

Presumably lots of stuff wrapped in 'unsafe'. I'm not a rust guy or a rust fan, and the last time I wrote something with Rust was like 7 years ago, but to my memory, because of how Rust manages mutability there are many access patterns that are Rust-specific; idiomatic Rust is going to use this patterns but they would be unlikely to show up in a language with a different type system / borrow checker / etc. etc.

So "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?'

How odd. Lot of mental gymnastics going on there.

The Bun author himself writes that the port is not idiomatic Rust:

    Do the rewrite that looks like we transpiled our Zig code to Rust. We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.

(from: https://bun.com/blog/bun-in-rust)

The original version of Bun was already a line-by-line (manual) port of esbuild from Go to Zig (also mentioned in this post), so the Zig code already wasn't "Zig-idiomatic" and apparently riddled with problems. That doesn't inspire much confidence in the LLM-translated Rust version tbh.

> That doesn't inspire much confidence in the LLM-translated Rust version tbh.

And yet Claude Code, which is the primary consumer, continues to chug away without any issue (that I, as a fairly heavy user, have encountered).

It's mostly the same in any general purpose programming language though, parts of the language features are meant (or became seens as) tools to be used in very narrow cases, which people less familiar with the language tend to "overuse".

Eg. goto/jump, bare "except" statements in python, etc... In Rust, unsafe has its uses and is a first class language feature, but it certainly isn't idiomatic to use it to mimic access patterns from other languages (unless absolutely necessary).

> "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?'

that is indeed a roughly accurate definition of what "unidiomatic" means

It means "don't misuse parts of the language in ways that circumvent best practices" one of which is "keep unsafe regions as small and few as possible" not "never use unsafe"

Meh. The (a major?) goal of Rust is this sort of type safety flowing down to memory bugs. Not every possible access pattern was known at the beginning, and generally they developed a philosophy of keeping the "unsafe" memory access patterns extremely bounded and heavily inspected. I think that's a fair and admirable goal.