undefined | Better HN

0 pointsrtpg1mo ago0 comments

I think the big difficulty here is that Rust's ownership model in particular tends to require certain kinds of control flow to avoid a bunch of weird churning/copying, which makes it not as straightforward of a port target from other imperative languages.

Like maybe you get the LLM to try _really hard_ to churn through everything, but this feels like a big case of "perils of the lack of laziness".

Of course if you have a good idea for how to deal with allocations etc "idiomatically" already maybe that works out well. And to the credit of the port guide writer bun seems to have its explicit allocations that are already mapping pretty well to Rust.

0 comments

3 comments · 1 top-level

pstuart1mo ago· 2 in thread

This is all wild conjecture, but I'd assume that teaching the LLM to do that mapping is an achievable goal and then it get's close to automatic -- effectively slurp the source AST into a rust AST and render.

My only experience with ports so far is Python to Go, and it's been near flawless (just enough stupid shit to make me feel justified to be in the loop).

rtpgOP1mo ago

It really isn't if you don't have the right abstractions.

Especially for memory management the right and wrong abstractions in Rust can lead to a factor of 5 or 10 extra amount of difficulty. The right memory management abstraction and your code can be a straight line port (or even cleaner!), the wrong one and you're going to just be spending a lot of tokens to have a machine spin around in circles trying to untie itself

GC'd languages don't have this problem, though obviously you can still generate stupid amount of pain for yourself by doing something wrong

spem-in-allium1mo ago

I'm porting a large-ish delphi application to c sharp. It's been pretty hands-off except for converting to async and some language capability mismatch.

j / k navigate · click thread line to collapse