[antonvs]

How would you have achieved this “machine translation” without an LLM?

It seems to me it would have been highly likely to be more expensive and more resource intensive - if realistically possible at all, short of implementing a general Zig to Rust translator first.

[electroly]

"Short of..." indeed. You already know the answer, although it doesn't need to be general; it only needs to work on a single codebase.

A recent and highly relevant example is the migration of the TypeScript compiler to Go. They did not use an LLM to translate the code. Instead, they used LLM assistance to write a deterministic TypeScript-to-Go translator and then used that to translate the code. I have far more confidence in this approach than in letting the LLMs rip on the translation itself.

[mewpmewp2]

I think TypeScript to Go is far easier to translate than something to Rust though.

[ForHackernews]

Is it? I wouldn't assume that. Go is a smaller and less flexible language than Java/Typescript (I say that as a compliment) so it's not clear to me that all Typescript idioms have an obvious Go equivalent.

Leaving aside ownership, Rust is a big, complex, expressive language. I'm not that familiar with Zig, but I think it tries to be a "better, modern C" so it seems like it should be easily possible to mechanically translate Zig into direct Rust equivalences. You probably won't get "good" idiomatic Rust at the end, but you should get working code that does the same thing.

[drzaiusx11]

Even before the advent of LLMs, I have personally (and largely successfully) translated several production systems from one language to another. I've learned it's best to start with a mechanical translation, literally bug for bug, leaving shit exactly as I found it (just in another language.)

I've done Perl to Java, Java to Kotlin, Python to Ruby, Ruby to Java, C to Swift, you name it.

It's only when you change behavior during the rewrite that it becomes an intractable problem. If you ship a 1:1 translation, THEN you can start going through the list of "bugs" you found along the way. Tread carefully when it comes to this, however, as I can almost guarantee that within your non-trivial codebase there will be some code that implicitly _depends_ on a "bug" to function at all. This where shit hits the fan.

[inamorty]

"Load bearing bugs"

[drzaiusx11]

It really is incredible how frequently these occur in everyday codebases of sufficient size.

[svieira]

We actually have a constant in our codebase to mark such bugs. You found one? Put it inside an:

    if (PREFER_EXISTING_BUGS_TO_NEW_ONES) { theOldBehavior(); }
    else { theNewBehavior(); }

Then, if we ever go to do a v2 of the thing, we can review these existing "load bearing bugs" and see if they make sense to change.

[drzaiusx11]

We do this via feature flags as well whenever "fixing" a non-trivial bug