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

351–360 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#351

Post by selfmodruntime »

akira2501 wrote: post #141
commodoreboxer wrote: post #51

A lot of people are reading this as a call or demand to translate all C and C++ code to Rust, but (despite the catchy project name), I don't read the abstract in that way. There are two related but separate paragraphs. 1. C and C++ just aren't safe enough at large. Even with careful programming and good tooling, so many vulnerabilities are caused by their unsafe by default designs. Therefore, as much code as possible…

> or written in "safe" languages So when those languages have 'unsafe' constructs what are the rules going to be around using those? Without a defining set of rules to use here you're just going to end up right back where you started. > to migrate to safe languages, which Rust is an example of Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not g…

> It is _not_ a safe language. To do anything interesting you will require unsafe blocks.

This is largely untrue. You can use proven abstractions over 99% of cases that would require unsafe.

Re: Translating All C to Rust (TRACTOR)

#352

Post by selfmodruntime »

akira2501 wrote: post #151
timeon wrote: post #144

Earlier quoted context omitted.

> To do anything interesting you will require unsafe blocks. This will not get you very much. This is not true.

> This is not true. Burying unsafe blocks in unevaluated cargo modules does not make this true. You're just taking the original problem and sweeping it under the rug.

You can rely entirely on crates that disallow unsafe to be included.

Re: Translating All C to Rust (TRACTOR)

#353

Post by poikroequ »

> Those involved with the oversight of C and C++ have pushed back, arguing that proper adherence to ISO standards and diligent application of testing tools can achieve comparable results without reinventing everything in Rust.

If you stick to extremely stringent coding practices and incorporate third party static verification tools that require riddling your code with proprietary situations, then sure, you can achieve comparable results with C/C++.

Or you can just use Rust.

Re: Translating All C to Rust (TRACTOR)

#354

Post by alkonaut »

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

A line-by line doesn't require much "AI" either. You could probably make a rough translation in some (mostly unsafe) Rust.

Assume the AI actually needs to figure out lifetimes and so on to be actually useful and make valid programs. Which would be impressive if it does.

Re: Translating All C to Rust (TRACTOR)

#355

Post by tonetegeatinst »

I am a total C shill....I'll admit it. I'm just starting to learn it and the only reason I picked it was I wanted a low level language that most systems run.

That said, while I can acknowledge the benefits of memory safety, I would personally choose zig over rust.

All things considered I know you can do some safety check for C using the compiler, and that helps reduce the odds of memory issues.

Idk what rust mail libraries look like( are they even called that?) But I know C's standard library's have made learning stuff easier. Is their any way to know if your libraries in rust are using unsafe code? Will that just spit out compile time errors?

Re: Translating All C to Rust (TRACTOR)

#357

Post by gosub100 »

slight tangent, but I think it would be amazing if AI could write device drivers. Full-featured GPU drivers for, say, OpenBSD. What does it need? Probably the state machines of the GPUs, how to enable various modes, how to feed data in/out of the device at intended speed, how to load shaders.

Why can't AI learn to do that? Its reward could be getting past the initialization and getting to the default state of the driver. It could be trained on hundreds of GPU drivers, not only for the minutiae of how to load values into the control registers, but the bigger picture of what it actually means.

Re: Translating All C to Rust (TRACTOR)

#358

Post by morgante »

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

Line by line is infeasible, which is precisely why you need to use AI to make larger semantic inferences.

You also don't have to one-shot translate everything. One of the valuable things about the Rust compiler is it gives lots of specific information that you can feed back into an LLM to iterate.

I've been working on similar problems for my startup (grit.io) and think C -> Rust is definitely tractable in the near term. Definitely not easy but certainly solvable.

Re: Translating All C to Rust (TRACTOR)

#359

Post by stogot »

morgante wrote: post #358
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."

Line by line is infeasible, which is precisely why you need to use AI to make larger semantic inferences. You also don't have to one-shot translate everything. One of the valuable things about the Rust compiler is it gives lots of specific information that you can feed back into an LLM to iterate. I've been working on similar problems for my startup (grit.io) and think C -> Rust is definitely tractable in the near te…

What about convert to AST then ask the AI to convert to Rust. Would that work?

Re: Translating All C to Rust (TRACTOR)

#360

Post by Someone »

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

> Pointers and aliasing are ubiquitous in c programs

If we ignore multi-threaded programs is long term aliasing actually ubiquitous in C programs? For many programs, I would expect most of it to happen within the scope of a single function (and within it, across function calls, but there, borrowing will solve this, won’t it?)

If so I would trying to tackle that as one sub-problem (you have to start somewhere), and detecting how data gets shared between threads as another. For the latter, I expect that many programs will have some implicit ownership rule such as “thread T1 puts stuff in queue Q where thread T2 will pick it up” that can be translated as “putting it in queue transfers ownership”.

Detecting such rules may not be easy, but doesn’t look completely out of reach for me, either, and that would be good enough for a research project.

Post reply on HN