Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DARPA project for automated translation from C to Rust (2024)

darpa.mil

Post reply on HN
Print view View original

51–60 of 194 posts

Re: DARPA project for automated translation from C to Rust (2024)

#51

Post by wmgries »

observationist wrote: post #25

Shouldn't they change it to WARPA to reflect the Dept of War name change? or even better: WARPATH: War Advanced Research Projects Agency for Technology and Hardware Say what you will about this administration, I do favor the more honest name. Defense carried connotations of peace and passivity that did no more than obfuscate the underlying nature of the military industrial complex. Maybe people will be more reluctant…

It feels more likely they'd shut down DARPA without realizing what it is than try to rename it.

Re: DARPA project for automated translation from C to Rust (2024)

#52

Post by bangaladore »

adastra22 wrote: post #15
bangaladore wrote: post #11

One of, in my opinion, the largest problem with Rust is that they sought to solve two problems: 1. Memory / thread safety 2. They didn't like C/C++ And often times it feels like there is more focus on problem two than problem one. Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting. I'd focus more on converting C/C++ to languages nearing…

Examples?

My best example of a "real" and not more artificial example (like XYZ data structure) is Game development / game engines & UI.

For reference: https://news.ycombinator.com/item?id=40172033

Re: DARPA project for automated translation from C to Rust (2024)

#53

Post by bangaladore »

convolvatron wrote: post #23
bangaladore wrote: post #11

One of, in my opinion, the largest problem with Rust is that they sought to solve two problems: 1. Memory / thread safety 2. They didn't like C/C++ And often times it feels like there is more focus on problem two than problem one. Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting. I'd focus more on converting C/C++ to languages nearing…

I don't think #2 is at all fair. I'm certainly of two minds about Rust and its ergonomics. But #2 seems to assume that C is some kind of default and canonical programming model, and to the extent that I like rust, its because they made different and internally consistent design choices.

C/C++ is the "default" language they are/were trying to replace with Rust. So I think it's fair to point out that Rust made design decisions explicitly contrary to design decisions of C/C++ style languages even though Rust is meant to replace it. That's going to (and does cause) problems.

Re: DARPA project for automated translation from C to Rust (2024)

#55

Post by woodruffw »

pizlonator wrote: post #31

(Sorry for talking about my personal project again y’all.) What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. The truth is: C as it is currently implemented is unsafe, and implementing it in a safe way is possible but we choose not because that would make it slower and use more memory . The…

> What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error.

I think what you’re doing with Fil-C is cool and interesting. But I think you’re talking past a large part of the “memory safety” audience with this framing: most people don’t want “memory safety” qua uncontrolled program termination, they want memory safety qua language semantics that foreclose on (many, if not all) things that would be memory-unsafe.

Or in other words: it’s great to be able to effectively be able to forklift C onto a managed runtime, but most people really want to be able to write code that doesn’t crash at all because of expressive limits in C’s semantics. “Memory safety” is a convenient term of art for this.

Re: DARPA project for automated translation from C to Rust (2024)

#56

Post by pizlonator »

AlotOfReading wrote: post #49
pizlonator wrote: post #31

(Sorry for talking about my personal project again y’all.) What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. The truth is: C as it is currently implemented is unsafe, and implementing it in a safe way is possible but we choose not because that would make it slower and use more memory . The…

There's plenty of reasons to prefer Rust to a memory-safe C. For example, I work on safety-critical code. That means that I have to review and affirm "This code implements my design". Making C memory-safe doesn't make the semantics of all UB defined or appropriate. Safe rust doesn't have UB, and validating unsafe rust isn't meaningfully different than doing it for C++, except that it's limited to tiny leaf functions…

> Making C memory-safe doesn't make the semantics of all UB defined or appropriate.

Fil-C largely gets rid of UB.

There are exceptions left but they’re all fixable.

The only reasons why C has UB are:

- lack of memory safety (Fil-C fixes this)

- policy (Fil-C mostly fixes this but there are still a small number of remaining issues, which I intend to fix).

Fil-C is super comprehensive in how it fixes C. I bet it’s more comprehensive than you’d expect.

The reason not to use Fil-C in safety critical systems is that some operations have varying cost and there’s a GC. The GC is concurrent so you might be able to make it suitable for safety critical hard realtime stuff; it would just be a lot of work and probably not worth it. Rust is better than Fil-C for hard real time stuff for that reason.

Re: DARPA project for automated translation from C to Rust (2024)

#57

Post by AlotOfReading »

hu3 wrote: post #50
IceHegel wrote: post #41

I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream. But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker…

> If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language. I beg to differ because Go has a large standard library which means less dependencies than Rust on average.

It's not usually the standard library or dependencies that create the issues I've seen. The teams I work with producing Go tools (across multiple companies) invariably require carefully orchestrated dev environments that are nigh-unreproducible. It's 50/50 on whether I can actually build a random project first try without reading the instructions if CGO is involved, which seems to be all of them.

My experience with random rust projects is that they usually "just build", with limited exceptions like weird embedded stuff.

Re: DARPA project for automated translation from C to Rust (2024)

#60

Post by the__alchemist »

foota wrote: post #43
IceHegel wrote: post #41

I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream. But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker…

This is a bizarre take to me, what do you want to do with classes that aren't supported by structs and traits? Imo the usability issues with rust arise from the borrow checker and associated complexity + restrictions on patterns, so I'm surprised that you're citing macros and classes.

I'm confused too! When I write Python, I do it in a similar style as rust, but knowing the classes and enums are sloppier than rust's; regarding mutation for example.
Post reply on HN