[pizlonator]

It’s wild that this is downvoted.

Converting all C++ code to Rust while actually getting a safety improvement is not possible because Rust does not safely support all of the things folks do in C++ (complex cyclic object graphs with inscrutable logic deciding lifetimes, intentional races, etc).

It’s easy to think that all of those “bad” things that C++ programmers do should somehow not have been done. It’s more likely that it’s either not possible to do it any other way or that you get a worse outcome if you do it another way. The cyclic nature of compiler IRs comes to mind. As do the wacky relationships between objects in games. Complex uses of syscall ABI are another. Oh and dynamic linking. Likely there are many other examples.

The idea that an LLM would convert C to Rust without introducing a slew of problems along the way is especially juvenile. Most likely the LLM with either use the unsafe subset of Rust, or produce Rust code that doesn’t actually match the functionality of the C code (but declare premature victory thinking that it did).

[AlotOfReading]

    Rust does not safely support all of the things folks do in C++ (complex cyclic object graphs with inscrutable logic deciding lifetimes, intentional races, etc).

The whole problem is that C++ doesn't support them safely either. The committee has no interest in fixing C++, so what's the alternative that doesn't involve a new language? DARPA already considered and rejected things like sandboxed runtimes and rewrites from scratch because they don't fully solve the issues.

[adastra22]

Do you have specific examples? All the areas you list are done in Rust too, where the borrow checker helps make sure they are bug free. Do you have an example of something that just can’t be represented in Rust’s type system?

[Havoc]

This is DARPA we're talking about. They've got a pretty good track record on pulling off stuff people we're convinced can't be done