DARPA project for automated translation from C to Rust (2024)

Rust Syntax, Aesthetics, and Ergonomics

• Several commenters find Rust “ugly” or cryptic, especially around sigils, lifetimes, Option/Result nesting, and method chains; they report not reaching a state where code “disappears” into intent as with Python or JS.
• Others argue the “ugly” parts correlate with genuinely hard problems (lifetimes, ownership) and intentionally signal complexity rather than hide it.
• Debate over whether Rust’s lack of “classes” is limiting: some miss class-style encapsulation; others point out Rust has access control and invariants via private fields + methods within modules.
• Many say the real ergonomics pain is the borrow checker and restricted patterns (esp. interior mutability), not surface syntax or macros; warts fade with experience.

Limits of Translating C/C++ to Rust

• Broad skepticism that arbitrary C/C++ can be automatically converted into safe Rust while preserving behavior and performance.
• Problem cases repeatedly cited: cyclic data structures (graphs, doubly-linked lists), complex object graphs in compilers and games, tricky syscall/ABI usage, UI frameworks, and legacy C++ patterns relying on aliasing and interior mutability.
• Rust can represent these, but often only via Rc/Arc + Weak, explicit cycle-breaking, raw pointers, or substantial redesign; semantics can change (e.g., graph lifetimes, deallocation behavior).

DARPA’s TRACTOR / ForCLift Strategy

• Program is C→Rust (not C++), with the awarded project using “verified lifting”:
  • Use analysis + LLMs to infer higher-level intent/idioms in C (e.g., pointer+len as a slice).
  • Translate to safe, idiomatic Rust (e.g., &[T], Vec<T>).
  • Apply formal methods to prove semantic equivalence.
• This is contrasted with tools like c2rust, which mostly preserve C semantics (including bugs) via unsafe Rust shims.

Alternative Approaches to Safer Legacy Code

• Fil-C: a drop-in, memory-safe C/C++ implementation using dynamic checks and GC; claims to catch a superset of Rust’s memory errors at runtime and largely eliminate UB while preserving source compatibility.
• Advocates say it’s ideal for securing large existing userspaces without rewrites; critics note GC and runtime panics are unacceptable for some safety-critical/real-time domains.
• Another project enforces a statically checked “safe subset” of C++ with tooling, claiming easier migration than to Rust and better handling of cyclic structures.

Memory Safety, Correctness, and Performance

• One side: C is “unsafe” only because we choose fast, unchecked implementations; a memory-safe C (via Fil-C or similar) plus tooling could suffice, with performance being the main Rust advantage.
• Others: static guarantees and Rust’s ownership model are crucial beyond memory safety (data races, invariants, concurrency reasoning); dynamic panics are the worst failure mode for many defense scenarios.
• Some emphasize that most real-world safety gains in recent decades have come from GC’d, dynamically checked languages (Java, C#, Python), not Rust—suggesting multiple viable paths.

Tooling and Ecosystem

• Strong praise for Rust’s unified tooling (cargo, testing, formatting) and relatively painless builds compared to C/C++ and often Go with CGO.
• Concerns about large Rust dependency trees and supply-chain risk acknowledged but seen as manageable with locking/auditing.
• Go and Zig are mentioned as having good build stories; Zig lacks Rust’s safety/type system, and Go’s CGO and dynamic linking limitations complicate some real-world setups.

Broader Defense / Naming Digression

• Brief tangent on whether “Department of Defense” should be renamed back to “Department of War” for honesty and accountability; others dismiss this as symbolic and unlikely to change military–industrial behavior.