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

81–90 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#81

Post by steveklabnik »

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…

> using AVX

This would require using unsafe code.

> As in: literally heartbroken. Unable to talk about it.

I would hope that this person improves as an engineer, because this isn't particularly professional behavior, from the way you describe it.

> "But the compiler said it was okay!"

Given that you'd have to use unsafe to do this, the compiler can't say it was okay. It sounds like this person may not fully understand Rust either.

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

I don't see how this generalizes. You had one (apparently junior, given "mentee"?) person make a mistake and respond poorly to feedback. You also barged into this thread and made incorrect statements about Rust, and were downvoted for it. That doesn't mean that Rust users think everything is perfect.

> As a community leader, do you see any room for improvement there?

I do think sometimes enthusiastic people who don't understand things misrepresent the thing they're enthusiastic about, but that's a human problem, not a Rust problem. I do not think there's a way to fix that, no.

Re: Translating All C to Rust (TRACTOR)

#82

Post by D-Coder »

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…

In addition to the other replies, this is a one-time project. After everything (or almost everything) has been translated, you're done, you won't be running into new edge cases.

Re: Translating All C to Rust (TRACTOR)

#83

Post by steveklabnik »

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

Their work was also previously sponsored by DARPA, though I do not know if it was under this program or something else.

Re: Translating All C to Rust (TRACTOR)

#84

Post by neonsunset »

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…

Don't worry, your language and especially the runtime and compiler are great. Particularly so in the last few years. I wouldn't worry about the noise, maybe it concerns C++, but C# is a strict productivity upgrade for general-purpose applications despite some* of the dated bits in the language (but not the runtime).

* like un-unified representation of nullable reference types and structs under generics for example, or just the weight of features over the years, still makes most other alternatives look abysmal in comparison

Re: Translating All C to Rust (TRACTOR)

#85

Post by nequo »

PreInternet01 wrote: post #74
commodoreboxer wrote: post #31

Earlier quoted context omitted.

> 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]

> ... in generally safe Rust.

Just to find agreement about the terminology, wouldn't we call all code that is not inside an unsafe block "safe?" If so, then adding "generally" is superfluous, right?

If not, then how is "generally safe" different from "not inside an unsafe block?"

Re: Translating All C to Rust (TRACTOR)

#86

Post by jerf »

PreInternet01 wrote: post #21
jerf wrote: post #9

Earlier quoted context omitted.

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…

[flagged]

I didn't expect you to outright confirm that you are using the "solve all programming problems ever" strawman, but, err, thanks for the proof I guess. I thought maybe I went a bit overboard in the reading between the lines but I guess I nailed it.

Re: Translating All C to Rust (TRACTOR)

#87

Post by 0cf8612b2e1e »

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)

Re: Translating All C to Rust (TRACTOR)

#88

Post by PreInternet01 »

steveklabnik wrote: post #68
PreInternet01 wrote: post #63

Earlier quoted context omitted.

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

> UB is not possible in safe Rust, by design

You're available as an expert witness to that fact?

Because, eh, well, in at least one of the Rust-related situations that I'm involved in right now, someone might soon very well require the services of a person both as wise and reluctant-to-offer-any-kind-of-compromise as yourself...

Re: Translating All C to Rust (TRACTOR)

#89

Post by 0cf8612b2e1e »

psychoslave wrote: post #61
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…

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.

Even if every project can only be 90% done, that’s a huge win. Best would be if it could just wrap the C equivalent code into an unsafe block which would be automatically triaged for human review.

Just getting something vaguely Rust shaped which can compile is the first step in overcoming the inertia to leave the program in its current language.

Re: Translating All C to Rust (TRACTOR)

#90

Post by steveklabnik »

PreInternet01 wrote: post #88
steveklabnik wrote: post #68

Earlier quoted context omitted.

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.

> UB is not possible in safe Rust, by design You're available as an expert witness to that fact ? Because, eh, well, in at least one of the Rust-related situations that I'm involved in right now, someone might soon very well require the services of a person both as wise and reluctant-to-offer-any-kind-of-compromise as yourself...

Yes, it is a core design tenet of the language. It's as benign a statement as "C# has garbage collection." That's not "reluctant to offer compromise."
Post reply on HN