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

131–140 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#131

Post by creata »

programd wrote: post #64
Calavar wrote: post #47

Earlier quoted context omitted.

> today cars drive themselves You can attach about a hundred asterisks to that. If anything, I think self the failure to hit L5 driving after billions of dollars and millions of man hours invested is probably reflective of how automatic C to Rust translation will go. We'll cruise 90% of the way, but the last 10% will prove insurmountable with current technology. Think about the number of C programs in the wild that r…

> > today cars drive themselves > You can attach about a hundred asterisks to that. Not in San Francisco. There are about 300 Waymo cars safely driving in one of the most difficult urban environments around (think steep hills, fog, construction, crazy traffic, crazy drivers, crazier pedestrians). Five years ago this was "someday" science-fiction. Frankly I trust them much more then human drivers and envision a future…

Isn't 100% accuracy (relatively) easy? c2rust already does that, or at least comes close, as far as I know.

Getting identical outputs on safe executions, catching any unsafe behavior (at translation-time or run-time), and producing efficient, maintainable code all at once is a million times harder.

Re: Translating All C to Rust (TRACTOR)

#132

Post by [deleted] »

the_snooze wrote: post #59
woodruffw wrote: post #25

Earlier quoted context omitted.

It's very hard; DARPA likes to fund hard things[1] :-). This isn't, however, DARPA's first foray into automatic program translation, or even automatic translation into Rust[2]. [1]: https://www.urbandictionary.com/define.php?term=DARPA%20hard [2]: https://c2rust.com/

DARPA is basically a state-sponsored VC that optimizes for completely different things. Instead of looking for 100x financial returns, they want technical advantages for the United States. The "moat" is the hardness of developing and operationalizing those technologies first.

[deleted]

Re: Translating All C to Rust (TRACTOR)

#133

Post by m0llusk »

programd wrote: post #64
Calavar wrote: post #47

Earlier quoted context omitted.

> today cars drive themselves You can attach about a hundred asterisks to that. If anything, I think self the failure to hit L5 driving after billions of dollars and millions of man hours invested is probably reflective of how automatic C to Rust translation will go. We'll cruise 90% of the way, but the last 10% will prove insurmountable with current technology. Think about the number of C programs in the wild that r…

> > today cars drive themselves > You can attach about a hundred asterisks to that. Not in San Francisco. There are about 300 Waymo cars safely driving in one of the most difficult urban environments around (think steep hills, fog, construction, crazy traffic, crazy drivers, crazier pedestrians). Five years ago this was "someday" science-fiction. Frankly I trust them much more then human drivers and envision a future…

Opinions about automated driving systems vary. Just from my own experience doing business all around San Francisco I have seen at least a half dozen instances of Waymo vehicles making unsafe maneuvers. Responders have told me and local government officials that Waymo vehicles frequently fail to acknowledge emergency situations or respond to driving instructions. Driving is a social exercise which requires understanding of a number of abstractions.

Re: Translating All C to Rust (TRACTOR)

#134

Post by eric-p7 »

0cf8612b2e1e wrote: post #87
thibran wrote: post #41

Porting the Linux kernel to 100% Rust should be the benchmark for AGI. ... and when done, please port SQLite too :)

I am fully in the RIIR koolaid, but SQLite would be near the absolute bottom of my prioritization list. Care to explain? SQLite is extensively tested, has requirements to run on ~every platform, be backwards compatible, and has a relatively small blast radius if there is a C derived bug. There is much more fertile ground in any number of core system services (network, sudo, dns, etc)

Not a small blast radius. There are an estimated 1 trillion active deployed SQLite instances: https://news.ycombinator.com/item?id=29461127

Re: Translating All C to Rust (TRACTOR)

#135

Post by nanolith »

pdimitar wrote: post #130
nanolith wrote: post #127

Earlier quoted context omitted.

> A huge investment. If you are going to do that then you might as well just move to Rust. People say that, but the people who say this rarely have any practical experience using CBMC. It's very straight-forward to use. I could teach a developer to use it reliably, on practical software, in a month.

I am not denying it, nor am I claiming that "just move to Rust" is an universal escape hatch. What I am saying is that if it were as simple as "just learn CBMC" then maybe Microsoft and Google would have not published their studies demonstrating that 60% - 75% of all CVEs are memory safety errors like buffer under-/over-flows.

These studies aren't wrong. But, that's also because neither Microsoft nor Google make use of practical formal methods in practice. Both have research teams and pie-in-the-sky projects, not dissimilar to this DARPA project. But, when it comes down to the nitty-gritty development cycle, both companies use decades old software development practices.

Re: Translating All C to Rust (TRACTOR)

#136

Post by mburns »

the_snooze wrote: post #59
woodruffw wrote: post #25

Earlier quoted context omitted.

It's very hard; DARPA likes to fund hard things[1] :-). This isn't, however, DARPA's first foray into automatic program translation, or even automatic translation into Rust[2]. [1]: https://www.urbandictionary.com/define.php?term=DARPA%20hard [2]: https://c2rust.com/

DARPA is basically a state-sponsored VC that optimizes for completely different things. Instead of looking for 100x financial returns, they want technical advantages for the United States. The "moat" is the hardness of developing and operationalizing those technologies first.

To be pedantic, In-q-tel is the literal state-sponsored VC.

DARPA is a step closer to traditional research labs but there is obviously some overlap.

https://en.wikipedia.org/wiki/In-Q-Tel

Re: Translating All C to Rust (TRACTOR)

#137

Post by marcosdumay »

jerf wrote: post #9
calebpeterson wrote: post #6

Earlier quoted context omitted.

Genuine question: Would you mind explaining to a dev that doesn’t know much (anything) about Rust, how does this settle any debate?

I believe it goes something like, "I have constructed a strawman that Rust claims that all code written in it is automatically safe by all conceivable definitions of safe, but look, ha ha, here's something that detects unsafe code in Rust!", and I don't mean "code marked in unsafe blocks". It's a concatenation of several logical fallacies in a row; equivocation, straw manning, binary thinking about safety, several ot…

> Of course, if the commentor is using anything other than Idris

I'm sure the Idris compiler has bugs somewhere too. If the OP actually programs, they are violating their rationale (I'm quite sure assembly or assembled binary aren't ok either).

Re: Translating All C to Rust (TRACTOR)

#138

Post by bornfreddy »

marcosdumay wrote: post #121
Animats wrote: post #103

Earlier quoted context omitted.

I've tried that thing. The Rust that comes out is terrible. It converts C into a set of Rust function calls which explicitly emulate C semantics by manipulating raw pointers. It doesn't even convert C arrays to a Vec. It's a brute-force transliteration, not a translation. I and someone else ran this on a JPEG 2000 decoder that sometimes crashed with a bad memory reference. The Rust version crashed with the same bad m…

Any automatic translation is bug-compatible with the original. Did you expect it to divine some requirements? It still leave you with Rust code that you can improve piecewise. The only question is if something like it is better than FFI calling the C code.

> Any automatic translation is bug-compatible with the original. Did you expect it to divine some requirements?

That would be useless when translating C to Rust. Yes, I would expect the tool to point out the flaws in the original memory handling and only translate the corrected code. This is far from easy, since some information (intent) is missing, but a good coder could do it on decent codebases. The question is, can an automated tool do it too? We'll see.

Re: Translating All C to Rust (TRACTOR)

#139

Post by uecker »

pdimitar wrote: post #37
nanolith wrote: post #27

I'm personally not a fan of "rewrite the world in Rust" mentality, but that being said, if one is planning to port a project to a new language or platform, mechanical translation is a poor means of doing so. Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece. Don't build a castle in the sky, because it will never reach the ground. If you've…

> I'm personally not a fan of "rewrite the world in Rust" mentality There is no such mentality anywhere. There is a ton of software that's much better off left alone in a dynamic language, or a statically typed language with a garbage collector (like Golang). Good engineers understand the idea of using the right tool for the job. The push is to start reducing those memory safety CVEs because they have been proven to…

Rewriting is rarely a good idea in general. Rust proponents like to pretend that it is impossible to avoid safety issues in C while it is automatically given in Rust. But this is not so simply in reality.

Re: Translating All C to Rust (TRACTOR)

#140

Post by sqeaky »

Calavar wrote: post #47
childintime wrote: post #33

Earlier quoted context omitted.

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.

> today cars drive themselves You can attach about a hundred asterisks to that. If anything, I think self the failure to hit L5 driving after billions of dollars and millions of man hours invested is probably reflective of how automatic C to Rust translation will go. We'll cruise 90% of the way, but the last 10% will prove insurmountable with current technology. Think about the number of C programs in the wild that r…

This is the exact formulation of the argument before computers beat humans at chess, or drew pictures, or represented color correctly, or... Self driving cars will be solved. There is at least one general purpose computer that can solve it already (a human brain), so of a purpose built computer can also be made to solve it.

In 10 (or 2 or 50 or X) years when Chevy, Ford, and others are rolling out cheap self driving this argument stops working. The important thing is that this argument stops working with no change in how hard C to Rust conversion is.

We really should be looking at the specifics of both problems. What makes computer language translation hard? Why is driving hard? One needs to be correct while inferring intent and possibly reformulating code to meet new restrictions. The other needs to be able to make snap judgments and in realtime avoid hitting things even if it just means stopping to prefer safety over motion. One problem can be solved piecewise without significant regard to time and the other solved in realtime as it happens without producing unsafe output.

These problems really aren't analogous.

I think you picked self driving cars just because it is a big and only partially solved problem. One could just as easily pick a big solved problem or a big unstarted problem and formulate equally bad arguments.

I am not saying this problem is easy, just that it seems solvable with sufficient effort.

Post reply on HN