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

121–130 of 194 posts

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

#121

Post by bangaladore »

waterTanuki wrote: post #64
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…

C++ and C# share a letter only. They operate in entirely different domains. You can certainly try to write PLC logic or a an IMU Sensor in C#, but that's probably not going to be a fun task.

I'm very familiar with both. My day job in defense is bare metal systems with C & C++ and often integrating them with C#-based test infrastructure.

Is C# perfect for every task, no. But it's probably suitable for most of the tasks that DARPA is targeting to support. The reality is that low-level languages were used in the past because generally our computers were less efficient, and the higher-level languages didn't exist. Most things today written in C++ would probably be written in a higher-level language if designed today.

Infact, I know of a specific case where a vendor is currently in hot water because a GUI tool running on a standard windows machine is not memory safe when in this case some agencies think it should be. This is probably similar to the vast majority of C++ code DARPA is concerned with.

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

#122

Post by hluska »

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…

The article doesn’t say the consensus was reached around Rust. That paragraph was talking about memory safety and so were both paragraphs around it. Rust isn’t even mentioned for two paragraphs after the part that annoyed you so much. But the first four paragraphs were all about memory safety.

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

#123

Post by bangaladore »

adastra22 wrote: post #85
bangaladore wrote: post #52

Earlier quoted context omitted.

My best example of a "real" and not more artificial example (like XYZ data structure) is Game development / game engines & UI. For reference: https://news.ycombinator.com/item?id=40172033

A bit surprised that you didn’t mention Bevy in your post. Have you worked with it?

Not my post, but I've heard the same concerns with Bevy as with the others. And the actual blog post linked by that post does mention Bevy many times.

Infact Bevy might be a perfect example of my gripe(s) with Rust. Completely throwing a standard object system out the window in-favor of ECS which still hasn't caught on in even the most used game engines like Unity hurts adoption and usability.

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

#124

Post by adastra22 »

pizlonator wrote: post #96
adastra22 wrote: post #81

Earlier quoted context omitted.

The kind of errors being protected against are totally different though.

Fil-C protects against a superset of the errors that Rust protects against. It just does it dynamically. And more comprehensively. There’s no `unsafe` statement in Fil-C. There’s no need for it since dynamic checking is vastly more precise.

Dynamic/runtime checks (and crashes) are VERY different from compile time checks though. Many applications, and especially those that DARPA are focused on, care about ahead-of-time guarantees that code will work correctly, and runtime panic is actually the worst possible failure mode. Think of flight control software, for example.

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

#125

Post by Rendello »

treyd wrote: post #116
jmull wrote: post #103

Earlier quoted context omitted.

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.

It's not comparable, comptime is more of an alternative to macros. You can build complex systems with it, but they don't natively give you the algebraic reasoning abilities that the typechecker does, at best you'd have to reimplement it yourself in an ad hoc way. Rust's proc macros are also fully programmable and have comparable expressive power to comptime.

I used Zig in the past (after my "why don't we just write everything simply in C" phase). I don't think I used comptime too much, but I understood why it would be useful.

Now I write Rust and absolutely love it, except for the damn macro edge cases, like not being able to use a known-at-compile-time string for format!() unless it's a literal (I even tried to fake it with more macros, no dice). I think Zig's Andrew Kelley mentioned this exact scenario, if I recall correctly.

It's funny because I do write a lot of code that generates code, but I avoid macros if I can.

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

#126

Post by duped »

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…

I would disagree, because people don't really care about memory safety for security reasons as much as I think gets talked about.

The most important safety mechanism in Rust is the borrow checker. It solves so many real problems that people willingly put up with the steep learning curve because that's easier than debugging data races and use after free.

Bounds checking is nice but it's not interesting or compelling enough to talk about as some ungodly super power of safety and security.

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

#127

Post by adastra22 »

bangaladore wrote: post #123
adastra22 wrote: post #85

Earlier quoted context omitted.

A bit surprised that you didn’t mention Bevy in your post. Have you worked with it?

Not my post, but I've heard the same concerns with Bevy as with the others. And the actual blog post linked by that post does mention Bevy many times. Infact Bevy might be a perfect example of my gripe(s) with Rust. Completely throwing a standard object system out the window in-favor of ECS which still hasn't caught on in even the most used game engines like Unity hurts adoption and usability.

I thought Unity and Unreal were transiting to ECS? I was under the impression at least that Bevy was adopting what the industry was moving towards, not exploring virgin territory.

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

#129

Post by mrheosuper »

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…

>dep hell

As a C programmer, i'm always a little panic how a small Rust Program can pull in that many crates when compiling.

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

#130

Post by jandrewrogers »

treyd wrote: post #92
sitzkrieg wrote: post #90

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.

Don’t underestimate Zig’s comptime or modern C++’s constexpr. You can use these to prove things about the program at compile-time far beyond the type system. In recent versions of C++, the scope of code that is compile-time verifiable is quite large, nothing like when it was first introduced 15 years ago.

This has limited (but not zero) applicability to memory safety but it has a lot of applicability to many other classes of defect against which Rust offers no special protection. Features like this are why modern C++ is still the language of choice for new software in high-assurance environments at DoD when performance matters. (When performance doesn’t matter it seems to be Java and C#.) These systems often have little or no legacy C++ code as a dependency, so that isn’t a factor.

I have less experience with Zig but this is an area where Rust can’t replicate the safety features of modern C++. With the introduction of compile-time reflection in C++26, this gap will increase. People who aren’t deep in it seriously underestimate what can be verified at compile-time in recent versions of C++ without the use of ugly arcana (which used to be required).

Post reply on HN