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

181–190 of 194 posts

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

#181

Post by array_key_first »

blub wrote: post #159
pornel wrote: post #104

Earlier quoted context omitted.

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

Many people know and like C. Many companies have access to plenty of C talent, but no Rust talent. These are two great reasons to try Fil-C instead of Rust. It seems that many Rustaceans think in terms of their own small community and don’t really have a feel for how massive the C (or C++) universe is and how many different motivations exist for using the language.

I agree, but the converse is also true and is where the value of this DARPA grant lies:

There's a lot of legacy C code that people want to expand on today, but they can't because the existing program is in C and they don't want to write more potentially unsafe C code or add onto an already iffy system.

If we can rewrite in Rust, we can get safety, which is cool but not the main draw. The main draw, I think, is you now have a rust codebase, and you can continue on with that.

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

#182

Post by array_key_first »

AnimalMuppet wrote: post #100
foota wrote: 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…

Rust has access control, and rust has better mutability and reference control. Many languages like C# and Java let you take references willy nilly and do almost whatever you want.

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

#183

Post by array_key_first »

torstenvl wrote: post #72
convolvatron wrote: post #23

Earlier quoted context omitted.

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.

But C is the default and canonical programming model. It is the native language of every major operating system. It is the language most closely tied to mainstream ISA assembly, and—symbiotically—which mainstream archs have tried to optimize for. It's one of few languages that are completely public, in the sense that it is not de jure or de facto owned by a single market participant. And it is the only language that…

For historical reasons. Which are very good reasons, but IMO we shouldn't just be forced to deal with the first somewhat okay solution we come up with for now until the end of time.

C is a fine language, but there are so many glaring and obvious mistakes.

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

#184

Post by array_key_first »

Ygg2 wrote: post #29
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…

> They didn't like C/C++ Riiiight. You do realize they made syntax similar to C/C++ on purpose to ease Mozilla's C/C++ programmers into it. It's not that they didn't like it; it's that C/C++ is about as disinterested in memory/thread safety as you can get. It's been what, ten years since Rust became 1.0? And the safety needle of C++ hasn't budged a femtometer. > Quite a bit of idiomatic and safe (yes that does exist)…

C++ is much more safe than C and has numerous safety contracts that are impossible to represent in C. Its always weird when C and C++ are thrown together.

Barne has talked about it, but one of the primary reasons he created C++ was to address safety issues in C. And he's talked about this since the early 90s.

Like access modifiers and private by default. Something we take for granted now, but something which is impossible in C.

Or std::vector. Unlike array in C, it won't blow up if you add too much stuff to it. Again, obvious, but at the time, revolutionary.

Or exceptions! We take them for granted to!

No more forgetting to check errno! No, if you don't catch an exception your program terminates, so you have to handle errors.

Or, the biggest one of all: RAII and ownership. Might sound familiar to rust devs!

Point is, C++ is not C. That's why C++ exists. Its not safe, but it's much, much safer.

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

#185

Post by array_key_first »

dymk wrote: post #67
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…

> They didn't like C/C++ What? > Quite a bit of idiomatic and safe (yes that does exist) C++ Reminds me of the “yes I’m vegan, yes I eat meat, we exist” meme.

C++ is an unsafe language, but there is lots and lots of safe C++ code. Most C++ code is safe, that's why every other line isn't a segfault. Safety, as a whole, is about catching edge cases.

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

#186

Post by heavyset_go »

james7132 wrote: post #155
heavyset_go wrote: post #136

Earlier quoted context omitted.

These are honest questions and not rhetorical: how does Zig handle versions with syntax changes or breaking changes? Can you mix Zig libraries written X years ago with modern Zig? Will today's code work in 5-10 years if I want to use it in a project then?

Zig has not hit 1.0 yet, and as recently as a few months ago completely reworked how every form of IO is written. AFAIK, this wasn't a syntax change, but it changed the function signature or type definition of every piece of code that reads/writes a file, establishes a connection, etc. At the current time, there is little guarantee that the code you write today will still work in 5-10 years time.

Thanks for the info, I was hoping there was something like Rust's editions that would allow for mixing libraries with differing language versions that have breaking changes.

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

#187

Post by 3836293648 »

kibwen wrote: post #131
3836293648 wrote: post #119

Earlier quoted context omitted.

Rust has exactly that. The difference is that rust considers the scope of private access te be the entire file it's defined in, not just its methods.

Just the module the struct is defined in, not the file. Easy mistake to make, given that a file is implicitly its own module, but you can create submodules within a file with the `mod` keyword.

I thought it crossed into submodules as well, making it the entire file?

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

#189

Post by voidmain »

junon wrote: post #177
tialaramex wrote: post #162

Earlier quoted context omitted.

I assume under the same "memory safety" rationale it just zeroes the RAM. That's "safe" and compatible with C. In a good language this mistake is caught at compile time, like in Rust, the compiler says "Hey, I don't see how this variable is initialized before use" and you slap your forehead and fix it. But zeroing everything is technically safe. For the Casey "hand made" Muratori type zeroing might even seem like a b…

I guess I don't see how making inherently incorrect C code "safe" by sanitizing something it shouldn't be doing anyway is actually improving the C code.

The key thing that memory safety provides is local reasoning. You can look at some important piece of code and conclude that it does the right thing, even if there are a million other lines of code somewhere else. UB makes this impossible; no matter how carefully you review dont_launch_missiles() it might launch the missiles due to an integer overflow in totally unrelated code in the same process.

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

#190

Post by correct_horse »

iberator wrote: post #150

Silly question: Let's say someone designed a C program that leaks memory for example in some unique way. Would RUST do the same? Would it happily auto translate erroneous code too?

Safe rust can leak memory, so a better question is "If someone wrote C code that made an invalid read or write, would rust do the same?" I can't answer the question, but ideally if the translated was safe, it would somehow eliminate the bug while keeping the desired behavior. That scenario seems a bit too optimistic though, so probably it'll have an unsafe block that does the invalid read/write and a human can come in and add runtime checks or refactor it further.
Post reply on HN