Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Translating All C to Rust (TRACTOR)

darpa.mil

Post reply on HN
Print view View original

341–350 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#341

Post by dlenski »

mike_hearn wrote: post #337
dlenski wrote: post #302

Earlier quoted context omitted.

Man, I want to upvote this but… > most interesting code is written in C++ anyway. Really?! The Linux kernel is a _pretty enormous_ counterexample, as are many of the userland tools of most desktop Linux distros. I am also a key developer of an entirely-written-in-C tool which I'd venture that [a large fraction of desktop Linux users in corporate environments use on a regular basis]( https://gitlab.com/openconnect/ope…

The refusal to use C++ in Linux isn't entirely rational. Nobody else makes that decision. Other kernels are a mix of C and C++ (macOS/iOS, Windows, even hobby operating systems like SerenityOS). Then you get into stuff that's not kernels and the user-spaces are again mostly all C++. The few exceptions that exist are coming out of the 90s UNIX culture, stuff like Apache or nginx. Beyond that it's all C++ or managed la…

> The refusal to use C++ in Linux isn't entirely rational.

Whether or not the decision not to use C++ is good or bad, rational or irrational, what is the relevance?

The point is that the Linux kernel is technologically interesting and innovative, under very active development, and it's written in C.

> The few exceptions that exist are coming out of the 90s UNIX culture, stuff like Apache or nginx. Beyond that it's all C++ or managed languages.

I literally just told you about a software project to which I contribute, which thousands of people and organizations use, which is written in C.

Also, it wasn't written in the ’90s.

Re: Translating All C to Rust (TRACTOR)

#342

Post by jcalvinowens »

bubberducky wrote: post #206
jcalvinowens wrote: post #70

This isn't some "pie in the sky" thing, Immunant has a working C to Rust transpiler and it's really interesting: https://github.com/immunant/c2rust

It seems easy (relatively speaking) to directly translate C to Rust if you're allowed to use unsafe and don't make an effort to actually verify the soundness of the code. But if you need to verify the soundness and fix bugs while translating it? That's really hard, and that's what it sounds like what TRACTOR wants to do. Using "unsafe" doesn't automatically make Rust useless, of course, but the example on the c2rust…

Eh, if c2rust "seems fairly easy" to you, I can pretty much guarantee you don't appreciate the complexity involved. Just take a look at the commit log...

Re: Translating All C to Rust (TRACTOR)

#343

Post by childintime »

childintime wrote: post #33
mike_hearn wrote: post #10

That sounds ... hard. Especially as idiomatic Rust as written by skilled programmers looks nothing like C, and most interesting code is written in C++ anyway. Isn't it equivalent to statically determining the lifetimes of all allocations in the C program, including those that are implemented using custom allocators or which cross into proprietary libraries? There's been a lot of research into this sort of thing over…

Hard for humans. But it's DARPA, is it hard for AI? Image classification used to be hard also, today cars drive themselves. I'd say it's good timing.

In my experience claude.ai has near perfect grasp of what a program (that fits its window) is written to do. It can already make a program in another language that can do the same. What this means is that the cost of a full rewrite is going to come down dramatically over the next few years.

This is an excellent example of government action I like to see, as it isn't about favoritism or the swamp dynamics. Just provide a target, a bounty and no or low barriers to entry.

This challenge does push Rust out in front of everybody. That's a mixed blessing. I hope this challenge gets modified to not specify the target language, but instead the requirement of memory and type safety. Rust is likely an intermediate stop on the way to something better, and it shouldn't matter if that language is called Rust 2.0 or something else.

Re: Translating All C to Rust (TRACTOR)

#344

Post by jdblair »

I'm really surprised this can work at all in any automated way. You can't just make a line-by-line transcription of a typical c program into rust. Pointers and aliasing are ubiquitous in c programs, concepts that rust explicitly prevents. You have to rethink many typical constructs at a high level to rewrite a c program in rust, unless you wrap the whole thing in "unsafe."

Re: Translating All C to Rust (TRACTOR)

#345

Post by alex_suzuki »

jdblair wrote: post #344

I'm really surprised this can work at all in any automated way. You can't just make a line-by-line transcription of a typical c program into rust. Pointers and aliasing are ubiquitous in c programs, concepts that rust explicitly prevents. You have to rethink many typical constructs at a high level to rewrite a c program in rust, unless you wrap the whole thing in "unsafe."

I wonder about this as well, especially im code bases that make heavy use of macros.

Re: Translating All C to Rust (TRACTOR)

#346

Post by ip26 »

jdblair wrote: post #344

I'm really surprised this can work at all in any automated way. You can't just make a line-by-line transcription of a typical c program into rust. Pointers and aliasing are ubiquitous in c programs, concepts that rust explicitly prevents. You have to rethink many typical constructs at a high level to rewrite a c program in rust, unless you wrap the whole thing in "unsafe."

For a naive newcomer - could you go line by line, wrap the whole thing in “unsafe”, compile to an identical binary, and then slowly peel away the “unsafe” while continuing to validate equivalence?

That would at least get you to as much rust as possible, and then let engineers tackle rethinking just those concepts.

Re: Translating All C to Rust (TRACTOR)

#347

Post by ip26 »

jandrese wrote: post #67
mike_hearn wrote: post #10

That sounds ... hard. Especially as idiomatic Rust as written by skilled programmers looks nothing like C, and most interesting code is written in C++ anyway. Isn't it equivalent to statically determining the lifetimes of all allocations in the C program, including those that are implemented using custom allocators or which cross into proprietary libraries? There's been a lot of research into this sort of thing over…

I have to think the approach will be something like "AI summarizes the features of the program into some kind of technical language, then the AI synthesizes Rust code that covers the same feature set". It would be most interesting if the approach was not to feed the program the original program but rather the manual for the program. That said it's rare that a manual captures all of the nuances of the program so a vie…

In theory, a codebase is a language precisely describing a program. The same program can be described in other languages. So that’s what you’re asking the LLM to do, in the same way you can describe a flower in either English or Spanish.

Re: Translating All C to Rust (TRACTOR)

#348

Post by rolph »

ip26 wrote: post #346
jdblair wrote: post #344

I'm really surprised this can work at all in any automated way. You can't just make a line-by-line transcription of a typical c program into rust. Pointers and aliasing are ubiquitous in c programs, concepts that rust explicitly prevents. You have to rethink many typical constructs at a high level to rewrite a c program in rust, unless you wrap the whole thing in "unsafe."

For a naive newcomer - could you go line by line, wrap the whole thing in “unsafe”, compile to an identical binary, and then slowly peel away the “unsafe” while continuing to validate equivalence? That would at least get you to as much rust as possible, and then let engineers tackle rethinking just those concepts.

you need to create a transpiler philosophy.

transform CtoASM, then ASMtoRust.

what you need to avoid is incompatibilites between different high level languages with a low level intermediary so you arent stuck attempting to convert high level hardware abstraction directly to another high level hardware abstraction.

Re: Translating All C to Rust (TRACTOR)

#349

Post by verdverm »

Russ Cox gave a GopherCon talk on the effort to automatically convert the Go compiler from C to Go (in the early days). Lots of interesting IRL issues / solutions in there.

https://www.youtube.com/watch?v=QIE5nV5fDwA

iirc, they were able to transpile 90%+ (without AI) and manually did the rest

Re: Translating All C to Rust (TRACTOR)

#350

Post by selfmodruntime »

ip26 wrote: post #346
jdblair wrote: post #344

I'm really surprised this can work at all in any automated way. You can't just make a line-by-line transcription of a typical c program into rust. Pointers and aliasing are ubiquitous in c programs, concepts that rust explicitly prevents. You have to rethink many typical constructs at a high level to rewrite a c program in rust, unless you wrap the whole thing in "unsafe."

For a naive newcomer - could you go line by line, wrap the whole thing in “unsafe”, compile to an identical binary, and then slowly peel away the “unsafe” while continuing to validate equivalence? That would at least get you to as much rust as possible, and then let engineers tackle rethinking just those concepts.

There are "warts" with unsafe Rust that would make this feat very difficult. Aliasing rules still apply.
Post reply on HN