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

41–50 of 194 posts

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

#41

Post by IceHegel »

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 and memory safety in my opinion.

If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language. It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno) and dep hell of Python (which was a nightmare until uv).

If Rust didn’t have the syntax warts (macros), it would be eating the world.

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

#42

Post by kspacewalk2 »

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…

What alternative to having a defense/war industry and stockpiling significant amounts of armour and arms intended for state sanctioned violence do you propose? Where do the actions of the current governments of the PRC, Russia and North Korea figure in this proposed setup? What do you think the consequences of the transition phase (not the final result) of your changes will be? Some possible quantifiable measures of the latter include number of additional wars fought, number of additional genocides perpetrated, number of additional millions killed in conflict; but you're free to choose your own.

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

#43

Post by foota »

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.

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

#44

Post by adastra22 »

pizlonator wrote: post #24
JoshTriplett wrote: post #22

Earlier quoted context omitted.

That's not at all a "we don't like C++" problem. That's "the chosen borrow-checking model makes cyclic structures hard, you have to do Rc/Arc and some manual management, or use unsafe and raw pointers". (Frankly, the latter is easier.)

Ref counting doesn’t work for cyclic data structures

Rc has downgrade and the Weak type explicitly for this purpose.

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

#45

Post by pizlonator »

NobodyNada wrote: post #39
pizlonator wrote: post #24

Earlier quoted context omitted.

Ref counting doesn’t work for cyclic data structures

Sure it does. Make the backreferences weak, or use a library that provides cycle detection (or even full-on tracing GC if you really want).

That changes the semantics. It won’t work for a graph for example.

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

#47

Post by adastra22 »

pizlonator wrote: post #17
adastra22 wrote: post #15

Earlier quoted context omitted.

Examples?

Doubly linked lists. Any cyclic data structure.

The easiest way to implement these is with Weak references in one of the directions. This requires some checking and/or locks, but the fact it is not trivial to do is kinda the point: the integrity of a cyclic data structure depends on managing multiple pointers in multiple structs simultaneously, and with that comes concurrency dragons.

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

#48

Post by k72siqqu »

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…

This is from 2024. Hegseth would want a language with a "warrior ethos", not Rust with its woke developers.

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

#49

Post by AlotOfReading »

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 with well-defined interfaces where a code reviewer can challenge you.

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

#50

Post by hu3 »

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.

Post reply on HN