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

71–80 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#71

Post by PreInternet01 »

timeon wrote: post #57
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…

> Well, the general 'Rewrite All in Rust' consensus is that it solves all general programming problems, ever. This is obvious example of strawman. Why are you doing this?

Towards general mental health. I'm just a C# wage slave, and I'll admit, when being prompted, that my language, its vendor, its runtime environment, and its general approach are, to put it kindly, flawed.

However, as evidenced by the arguments and voting in this thread, Rust proponents will take no criticism, whatsoever.

I linked to a GitHub repository that documents many, many instances in which generally safe Rust causes UB.

The same kind of UB that recently hit one of my coworkers, caused a 3-day outage and now (despite all my counseling to the contrary!) will burn them out permanently.

My only request: can you guys please back off just a little bit? Programming is already hard enough without the purity wars you're stoking all the time...

Re: Translating All C to Rust (TRACTOR)

#72

Post by woodruffw »

deepsun wrote: post #66
woodruffw wrote: post #45

Earlier quoted context omitted.

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.

I’m not assuming anything of the sort. These are just properties that make Rust a nice target for automatic translation of C programs; there are myriad factors that guarantee that nowhere close to 100% of programs (C, application level, or otherwise) won’t be suitable for translation.

Re: Translating All C to Rust (TRACTOR)

#73

Post by jll29 »

Difficult: most C programs I know would convert to one single large "unsafe" block...

One might argue that re-writing from scratch is the safer option; and a re-write is also an opportunity to do things differently (read: improve the architecture by using what one has learned), despite the much-feared "second system" syndrome.

But nothing wrong with spending some research dollars towards tooling for "assisted legacy rewrites". DARPA and her sister IARPA fund step innovation (high risk, high reward), and this is an area where good things can come potentially come from.

Re: Translating All C to Rust (TRACTOR)

#74

Post by PreInternet01 »

commodoreboxer wrote: post #31
PreInternet01 wrote: post #21

Earlier quoted context omitted.

[flagged]

> This repository demonstrates that, when using 'safe' Rust, there are still double-digits cases where you may still encounter dread-pirate-UB. No it doesn't. Miri is for unsafe code. There's no UB in safe Rust by design. Any UB caused without unsafe is considered a bug to be fixed.

[flagged]

Re: Translating All C to Rust (TRACTOR)

#75

Post by n_plus_1_acc »

PreInternet01 wrote: post #62
steveklabnik wrote: post #26

Earlier quoted context omitted.

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 th…

The Rust community as a whole very much promotes the idea of trusting the Compiler. Which is a very useful thing, especially for folks coming from other languages like C. It's not perfect of course as the compiler has bugs, but I think it still a good thing to teach.

Re: Translating All C to Rust (TRACTOR)

#77

Post by munificent »

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…

More like:

"AI more or less sort of summarizes the features of the program into some approximate kind of technical language, then the AI synthesizes something not too far from Rust code that hopefully covers aspirationally the same feature set".

Re: Translating All C to Rust (TRACTOR)

#78

Post by downrightmike »

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…

If the IRS could have more timely funding, all their Cobol would be translated to Java by now

Re: Translating All C to Rust (TRACTOR)

#79

Post by Calavar »

keybored wrote: post #32
PreInternet01 wrote: post #18

Earlier quoted context omitted.

> What on Earth do you mean? That documented use of safe Rust can easily lead to UB, which this infernal 'internal compiler representation' demonstrates. I'm not even sure what is even remotely confusing about that?

Indeed. There have been UB bugs in the standard library caused by unsafe blocks. Those are bugs. They are faults in the code. They need to be fixed. They are not UB-as-a-feature like in C/C++. “Well watch out for those traps every time you use this.” This is like getting mad that a programming language boasts that it produces great binaries and yet the compiler has a test suite to catch bugs in the emitted assembly.…

> Those are bugs. They are faults in the code. They need to be fixed. They are not UB-as-a-feature like in C/C++.

Rust has UB-as-a-feature too. They could have eliminated UB from the language entirely, but they chose not to (for very valid reasons in my opinion).

UB is a set of contracts that you as the author agree to never violate. In return, you get faster code under the assumption that you never actually encounter a UB condition. If you violate those contracts in Rust and actually encounter UB, that's a a bug, that's a fault in the code. If you violate those contracts in C++, that's a bug, that's a fault in the code. This is the same in both languages.

It's true that Rust UB can only arise from unsafe blocks, but it is not limited to unsafe blocks. Rust UB has "spooky action at a distance" the same way C++ UB does. In other words, you can write UB free code in Rust, but if any third party code encounters UB (including the standard library), your safe code is now potentially infected by UB as well. This is also the same in both languages.

There are good reasons to favor Rust's flavor of UB over C++'s, but I keep seeing these same incorrect arguments getting repeated everywhere, which is frustrating.

Re: Translating All C to Rust (TRACTOR)

#80

Post by eesmith »

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.

As a reminder, DARPA funded self-driving car research since at least the 1980s with the Autonomous Land driven Vehicle (ALV) project, plus the DARPA Grand Challenges, and more.
Post reply on HN