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

61–70 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#61

Post by psychoslave »

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…

Ok, but if it's like 90% of small projects can use it as direct no pain bridge, that can be a huge win.

Even if it's "can handle well 90%" of the transition for any project, this is still interesting. Unlike cars on the road, most code transition project out there doesn't need to be 100% fine to provide some useful value.

Re: Translating All C to Rust (TRACTOR)

#62

Post by PreInternet01 »

steveklabnik wrote: post #26
commodoreboxer wrote: post #22

Earlier quoted context omitted.

> Miri is an Undefined Behavior detection tool for Rust. It can run binaries and test suites of cargo projects and detect unsafe code that fails to uphold its safety requirements. > ... detect unsafe code that fails ... Show me the documented safe Rust code that causes UB without using any unsafe blocks outside of the standard library.

There are some soundness holes in the implementation that can cause this. Just like any project, the compiler can have bugs. They’ll be fixed just like any bug.

Ah, a voice of sort-of sanity, at long last.

So, the reason I posted my original reply, is that at one of my $DAYJOBs, we recently had a 3-day outage on some service, related to Rust. Something like using AVX to read, like, up to 7 bytes too many from an array.

Nothing really major -- we have a 10-day backup window, and the damage was limited to 4 days, so we were able to identify and fix all identified cases. But the person-to-Git-blame for this issue happened to be one of my mentees, and... they were blown away by it.

As in: literally heartbroken. Unable to talk about it. "But the compiler said it was okay!", crying. One of my coworkers pointed at MIRI, which correctly warned about the issue-at-hand, at which point I recommended incorporating that tool into the build pipeline, as well as (the usual advice in cases such as this) improving unit tests and focusing on X-1 and X+1 cases that might be problematic.

To this day, I'm truly worried about my mentee. I'm just a C# wagie, and I fully accept that my code, my language, my compiler, and my runtime environment are all shit.

But, as evidenced by my experience and supported by the voting in this thread, it seems that Rust users seem to self-identify with the absolute infallibility of anything relate to the language, and react quite violently and self-destructively to any evidence to the contrary.

As a community leader, do you see any room for improvement there? And if not, what would it take to convince you?

Re: Translating All C to Rust (TRACTOR)

#63

Post by PreInternet01 »

steveklabnik wrote: post #30
PreInternet01 wrote: post #15

Earlier quoted context omitted.

Well, the general 'Rewrite All in Rust' consensus is that it solves all general programming problems, ever . Yet, the linked repository shows a huge list of cases in which simple, documented use of Rust can cause Undefined Behavior (a.k.a. 'UB') Pretty much every argument of Rust advocates against C/C++ boils down to either 'but memory safety' or 'but UB'. Yet there are many convincing counter-arguments that boil dow…

No serious person claims that Rust solves every problem ever. Also, many people cite things like Cargo as a reason to prefer Rust over C and C++, as well as other things. UB is a big part of it, of course, but it isn’t the only thing.

> No serious person claims that Rust solves every problem ever

No, but there are a lot of people claiming that Rust cannot ever have any problems.

Just look at this thread. I merely linked to MIRI, and am currently at, like, -10 just for that.

Lots of people claiming that it just applies to 'unsafe Rust': is that true or not?

Regardless of anything else: can you, as a Rust community leader, please state clearly: is UB in generally safe Rust possible or not?

Re: Translating All C to Rust (TRACTOR)

#64

Post by programd »

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…

> > 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 utopia where human drivers are banned from urban centers.

To get back on topic, I don't think automatic programming language translation is nearly as hard, especially since we have a deterministic model of the machines it runs on. I can see a possible approach where AI systems take the assembler code of a C++ program, then translate that into Rust, or anything else. Can they get 100% accuracy and bit-for-bit compatibility on output? I would not bet against it.

Re: Translating All C to Rust (TRACTOR)

#65

Post by spease »

calebpeterson wrote: post #6
PreInternet01 wrote: post #3

The one link for those who think that 'Rewrite it All in Rust' will, well, settle any debates: https://github.com/rust-lang/miri/

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

They are claiming that because code in ‘unsafe’ blocks in Rust can have undefined behavior, that the language is no safer than C.

This does not settle the debate because unsafe is rarely needed for a typical Rust program. In addition, the presence of an unsafe block also alerts the reader that the set of possible errors is greatly increased for that part of the code and more careful auditing is needed.

It’s a little like saying traffic lights are useless because emergency responders need to drive through them sometimes, so we should just leave intersections completely unsignaled and expect drivers to do better.

Rust is by default restrictive and requires you to explicitly make it unsafe, C/++ are by default unsafe and require you to explicitly make them restrictive.

Re: Translating All C to Rust (TRACTOR)

#66

Post by deepsun »

woodruffw wrote: post #45
deepsun wrote: post #39

They didn't explain why they've chosen Rust. There are a lot of memory-safe languages besides Rust, especially in application-level area (not systems-level like Rust).

There are a lot of memory safe languages; there are fewer that have (1) marginal runtime requirements, (2) transparent interop/FFI with existing C codebases, (3) enable both spatial and temporal memory safety without GC, and (4) have significant development momentum behind them. Rust doesn't have to be unique among these qualifications, but it's currently preeminent.

Yes, but you assume all their projects need all 4 of these. I like Rust, but it's a bad choice for many areas (e.g. aforementioned application-level code). I'd expect serious decisions to at least take that into account.

Re: Translating All C to Rust (TRACTOR)

#67

Post by jandrese »

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 view into the source code is probably necessary, at least for getting the ground truth.

Re: Translating All C to Rust (TRACTOR)

#68

Post by steveklabnik »

PreInternet01 wrote: post #63
steveklabnik wrote: post #30

Earlier quoted context omitted.

No serious person claims that Rust solves every problem ever. Also, many people cite things like Cargo as a reason to prefer Rust over C and C++, as well as other things. UB is a big part of it, of course, but it isn’t the only thing.

> No serious person claims that Rust solves every problem ever No, but there are a lot of people claiming that Rust cannot ever have any problems. Just look at this thread. I merely linked to MIRI, and am currently at, like, -10 just for that. Lots of people claiming that it just applies to 'unsafe Rust': is that true or not? Regardless of anything else: can you, as a Rust community leader, please state clearly: is U…

No, people are not claiming Rust cannot have any problems.

UB is not possible in safe Rust, by design. The root cause of UB is always in unsafe code. Miri is useless if your code is 100% safe Rust.

The only exception to this is bugs in the compiler, of which there are a few. They’ll be fixed.

Re: Translating All C to Rust (TRACTOR)

#69

Post by wffurr »

0xbadcafebee wrote: post #54

Every tool has its own specific quirks. Over many years of using a tool, "expertise" is the intimate knowledge of those quirks and how to use that tool most effectively. Changing tools requires you to gain expertise again. You're going to be less proficient in the new tool for a long time, and make a lot of mistakes. Considering we already know how to make C/C++ programs memory safe, it's bizarre that people would di…

But even proficient C and C++ programmers continue to produce code with memory safety issues leading to remote code execution exploits. This argument doesn’t hold up to the actual experience of large C and C++ projects.
Post reply on HN