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

Post by kibwen » Thu, Oct 02, 2025, 2:34 AM UTC

3836293648 wrote: post #119

AnimalMuppet wrote: post #100

Earlier quoted context omitted.

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

Post by Splizard » Thu, Oct 02, 2025, 2:39 AM UTC

pizlonator wrote: post #115

scottlamb wrote: post #101

Earlier quoted context omitted.

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

I think what you’re saying is true for the kind of software where it isn’t just greenfield but also doesn’t have to make deep use of preexisting system dependencies. Like, say you’re writing a port daemon. Then your argument holds! And that’s admittedly a big category since it includes databases, application servers, and a lot of other stuff. But say you’re writing an app that talks to systemd and your desktop shell…

Post by mrheosuper » Thu, Oct 02, 2025, 2:43 AM UTC

mikepurvis wrote: post #5

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…

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…

  let x: Option, std::num::ParseIntError>> = Some(Ok(vec![1, 2, 3]));
  let flattened = x
 .map(|r| r.unwrap_or_default())
 .unwrap_or_else(|| Vec::::new());

Post by kibwen » Thu, Oct 02, 2025, 2:44 AM UTC

bangaladore wrote: post #53

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.

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.

Post by woodruffw » Thu, Oct 02, 2025, 2:53 AM UTC

pizlonator wrote: post #91

woodruffw wrote: post #55

Earlier quoted context omitted.

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

I’m not inventing a definition for memory safety out of thin air, so I think there’s just a tendency to conflate Rust’s static checking with memory safety. Rust’s most important safety mechanism is panicking on out of bounds access. OOBA’s are the thing that attackers most want to do, and Rust, Fil-C, and almost all of the other memory safe languages solve that with runtime checking. In short, I’d say what Rust gives…