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

31–40 of 194 posts

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

#31

Post by pizlonator »

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

(It’s also annoying that this DARPA page mentions some kind of consensus. There’s no consensus on Rust being the safe bet. Lots of orgs are going with alternatives, like Swift, Zig, C++-with-changes, or other things.)

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

#32

Post by mynameisash »

andrewmcwatters wrote: post #7
mikepurvis wrote: post #5

Earlier quoted context omitted.

What are the specific aesthetic complaints here? In my limited rust experience, I’ve found that it does a pretty good job of using the ugliness of something like an explicit lifetime to signal to the developer and reader that the code is doing something complicated and non-obvious. Like “here’s a part where the types logic required more help than what the compiler could figure out on its own; here be dragons.” In tha…

Some of my complaints are petty, and I think can be dismissed as just personal preference. I don't have a great deal of complaint with languages with different syntax, just ones that are so intentionally cryptic so as to invent needless specific sigils that you need to memorize. I agree that most of the awkwardness of reading comes from explicit declarations, but really, even if it's more verbose, I would prefer that…

> just ones that are so intentionally cryptic so as to invent needless specific sigils that you need to memorize.

Can you back up this claim that the language is intentionally cryptic?

Ignoring that: other languages have sigils (Perl's @, $, %, etc.; PHP has always used $; Java uses @ annotations, and so on) or their own quirky syntax (C#'s custom attributes before a class, Python's @ decorators, etc.). What is it about Rust that is particularly confusing?

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

#33

Post by cozzyd »

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…

Wait until Hegseth learns about the "safety" ethos present in rust and how heavy the binaries can be.

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

#34

Post by adastra22 »

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…

Does your thing add linear types, borrow checking, and remove implicit conversions from C?

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

#35

Post by hobs »

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…

I will say what I will - what a pointless change that will yield nothing, literally virtue signalling. Nobody selling to the DoD is going to "yuck" after the word "war" is now part of the game, we've basically been continuously killing people since WW2.

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

#36

Post by JoshTriplett »

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

It doesn't fully handle the memory management, but it handles having shared references. You can use weak references or manually break the links when you want to free something. Or you can use unsafe raw pointers, which frankly seem simpler. Either way you're going to wrap it in a data structure that encapsulates all the details.

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

#37

Post by AlotOfReading »

pizlonator wrote: post #16
andrewmcwatters wrote: post #2

Maybe I just need to spend more time with Rust and deal with it, but I'm sad the industry desires to rally around it. Despite the specific subset of protections it aims to provide, I have always had issues with how ugly the language is. To a lesser extent, I have a problem with the protections it doesn't provide and leads developers to think they're writing safe software that in specific cases, actually just promotes…

It’s wild that this is downvoted. Converting all C++ code to Rust while actually getting a safety improvement is not possible because Rust does not safely support all of the things folks do in C++ (complex cyclic object graphs with inscrutable logic deciding lifetimes, intentional races, etc). It’s easy to think that all of those “bad” things that C++ programmers do should somehow not have been done. It’s more likely…

    Rust does not safely support all of the things folks do in C++ (complex cyclic object graphs with inscrutable logic deciding lifetimes, intentional races, etc).
The whole problem is that C++ doesn't support them safely either. The committee has no interest in fixing C++, so what's the alternative that doesn't involve a new language? DARPA already considered and rejected things like sandboxed runtimes and rewrites from scratch because they don't fully solve the issues.

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

#38

Post by the__alchemist »

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…

Unfortunately, I don't think that's avoidable. This is equivalent to lamenting not being able to use Haskell-style pure FP, nor object inheritance. There are C++ (and C) design patterns that will just not work in rust, or won't work in an ergonomic way. The solution is to solve the problem in a different way.

I will add a #3 to your list: Make an all-around nice language I think playing up rust as the memory-safe language underplays its value.

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

#39

Post by NobodyNada »

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

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

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

#40

Post by pizlonator »

adastra22 wrote: post #34
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…

Does your thing add linear types, borrow checking, and remove implicit conversions from C?

Definitely not. Then it wouldn’t be a C implementation.

Fil-C is so compatible that I have a Linux userland compiled with it https://fil-c.org/pizlix

Think of Fil-C as Java-ifying C an C++

Post reply on HN