Comment by fdsajfkldsfklds

17 hours ago

This is effectively a very expensive and resource-intensive machine translation. As such, there is no increase in consistency or quality of output.

8 comments

fdsajfkldsfklds

Reply
Aurornis  16 hours ago

The translation is a starting point to enable follow-on work to take advantage of Rust's features.

antonvs  12 hours ago

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  10 hours ago

    "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.

  • drzaiusx11  11 hours ago

    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.