Live data from Hacker News

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

darpa.mil

101–110 of 194 posts

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

#101

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

> The argument for using Rust instead of a memory safe implementation of C is all about performance. And that’s not a bad argument! But we should be honest about it.

I think it might also be that people mostly consider languages from the perspective of what they'd write a greenfield codebase in. And if I'm gonna pay the GC cost, I'd much rather work with language/library body that doesn't have tons of ownership idioms that are basically irrelevant with a GC. So it's not Fil-C vs Rust directly; it's Fil-C vs Go (Go wins), then Go vs Rust (more interesting decision).

But for existing large C projects that are ancient enough that running on modern hardware far outweighs the new GC cost, and that are mature/minimally maintained so the development costs for a rewrite/translation won't ever pay off in future maintenance, I think Fil-C is an intriguing option.

btw, IMO Rust has more going for it than just the borrow checker.

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

#102
post #94

Earlier quoted context omitted.

Rust projects which depend on C libs have very similar issues.

I haven't experienced this. Rust's build system allows you to automate most of the pain in building/bundling those dependencies, so it's just up to the builder to have the right headers (if they're not bundled). That makes it no worse than meson C/C++ builds. In Go, it doesn't have any of that so it depends on the end builder of the binary to be aware of all the C dependencies and manually manage integrating the cgo…

Its highly dependent on the kind of project. A few years back libxml and libxmlsec1 were a consistent pain in the neck for me. I don't know about now, I simply moved on from the project that needed me to interact with them.

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

#103
post #92

Earlier quoted context omitted.

> If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language zig is very comparable, and much faster at doing so. zig also comes with a build system, libc and can compile c programs. its a better c compiler and build system than most, lol.

But Zig doesn't have the very sophisticated type system that Rust has. Nor does it, importantly to DARPA, have the memory safety that Rust does.

A type system in programming languages is a way to express and enforce compile time constraints (conventionally, anyway).

zig's type system is pretty straightforward, but its comptime is very powerful and, among other things, can enforce arbitrary compile time constraints. It's not the same as rust's types, but I wonder if it isn't better in many ways.

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

#104

(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, the…

Another aspect is that the majority of projects that keep using C, do it specifically to maximize performance or low-level control (codecs, game engines, drivers, kernels, embedded).

For such projects, a GC runtime goes against the reason why they used C in the first place. Rust can replace C where Fil-C can't.

A technically memory-safe C with overhead is not that groundbreaking. It has already been possible with sandboxing and interpreters/VMs.

We've had the tradeoff between zero-overhead-but-unsafe and safer-but-slower languages forever, even before C existed. Moving C from one category to the other is a feat of engineering, but doesn't remove the trade-off. It's a better ASAN, but not miraculously fixing C.

Most projects that didn't mind having a GC and runtime overhead are already using Java, C#, Go, etc. Many languages are memory-safe while claiming to have almost C-like performance if used right.

The whole point of Rust is getting close to removing the fast-or-safe tradeoff, not merely moving to the other side of it.

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

#106

Earlier quoted context omitted.

Right. The comment you replied to said "Rc/Arc and some manual management" -- "some manual management" implying that you need to account for the change to semantics in the manner appropriate for your application.

(Note that I edited my comment for clarity since the original reply. My original comment just said "reference counting".)

The key part I agree with most in your edited comment is that unsafe raw pointers are the easiest way to deal with cycles.

I think this is key. RC pointers don’t give you the ability to say: ok, I now know that this subset of the graph is dead because reasons so delete it. In RC, you’d have to walk the graph to break cycles. That’s a rather important difference from how you’d manage a cyclic data structure in C, C++, Java, C#, or any GC’d language. In C/C++, you’d delete what you know to be dead; in Java et al it would be enough to kill the references that point at the outer edges of the dead subgraph. But you wouldn’t have to walk the subgraph to detangle the cycle.

I think it really is worse than that; ie as you say, folks will just do anything but RC in that case. In Rust the safe bet would be to just shove all the nodes into an array and use indices (yuck!!!). But likely a lot of code with use raw pointers instead (also yuck). The whole thing where you reference count cyclic data structures is just too painful for sensible people

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

#107

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…

Oh, no alternative proposed. The US has lost 10+ trillion to what amounts to an unaccountable budgetary black hole, however, and limiting the awful dingleberry NGOs and private contractors and horde of companies and people that exploit the need for miltary R&D is a good thing.

The US should definitely keep doing R&D, the tech that comes out of DARPA has lots of downstream benefits beyond military applications. We should continue producing the best tech in the world, and explore all sorts of skunkworks and moonshots and crazy tinkering. I agree with "peace through strength" - be too dangerous to abuse, and if shit goes down, be the one who decides who wins and loses.

We don't need a corrupt military industrial complex, endless wars, private contractors, NGOs, nepo-grifters, and all the rabble that have abused the lack of accountability to make themselves rich, or inflict unrest on other countries, or manipulate bureaucracy for political gain, and all that jazz. Basic things like "department of war" naming fall in that direction, from my perspective. Simplify, cut, use blunt truthful language, and figure out how to hold them accountable going forward, at the very least, and at best, figure out how to claw back the trillions, or figure out where it went. You don't need to alter the underlying mission at all, really.

See, there's this notion that the US is a bad guy, and they point out all the casualties and conflicts and collateral damage and say "see, we're the baddies!" They never account for the context. Some of it is as simple as pointing out that if we hadn't killed all those german nazis, and sought pacifism and peace at any price, we'd all be speaking German. Some legitimate atrocities have occurred, as recently as Obama's unnecessary drone murders, but ranging from improper harms done to US troops, exposure to toxins, Abu Ghraib abuses of civil liberties, some of what's happened at Gitmo, etc. Each and every time we recognize a harm done, we should at the very least hold ourselves, collectively, responsible, and seek to be better. Accountability is a civic duty, regardless of political affiliation or philosophy. We should also be honest about necessary evils, not allow ourselves to be manipulated by bad faith actors, back up positions and words with actions and force, and hold ourselves to the highest possible standards. If we find ourselves continuously presented with no alternatives except between two evils, we should choose the lesser evil which allows us to preserve ourselves (otherwise, what are we even doing?)

The US body politic has allowed assumptions of good faith by our bureaucrats and military brass and politicians to fester into unimaginable corruption and vice, proving Eisenhower a prophet. We should simply be better - little things, important things, ground up discipline, principles, and a persisted social construct upon which to stably build a nation's strength is 100% necessary.

A lot of what Trump and Hegseth are doing pushes in that direction. Some aspirational, some performative, some well intentioned but wrong, but I think it's mostly in good faith, and I can get behind that.

I wish more on the left would at a bare minimum wish everyone to be responsible and to do well, for everyone to be happy, healthy, prosperous, and free. It has to be permitted to hope that whoever is in power achieves victories and success in those basic things, or we've lost the plot.

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

#108
post #43

Earlier quoted context omitted.

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.

Access control. Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created. You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class . The sur…

Ah, that makes some sense, although some reading says that struct member visibility is by default the module, which is a file if you don't do anything. If you wanted you could probably just wrap all the structs you want to be protected inside a module per file? It is a bit annoying though. I guess the issue here is that in rust struct fields need to be accessed for trait implementations. It wouldn't be backwards compatible obviously, but I wonder if they could have tightened that so that by default only trait implementations for a struct can access that structs members?

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

#109
post #43

Earlier quoted context omitted.

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.

Access control. Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created. You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class . The sur…

You can do exactly this in rust using non public fields and accessor methods.

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

#110
post #50

Earlier quoted context omitted.

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

I worked for 10 years with Go and almost never seen a cgo dependcy, it's far more common in Rust, it's not even comparable. Rust replaces tons of c/c++ so it has more ffi.

The vast majority of Go code, like 99% doesn't have a single cgo dependency.

Post reply on HN