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 silent failure through invalid data, not crashing.
I'm impressed that the language is even uglier than bad C++, which is an accomplishment in violating the beauty of reading.
Edit:
No, I think complicated C++ is also distasteful, but equally, sometimes both are just simply necessary.
Annotating specific attributes of data flow is just a requirement for types of guarantees, but I wish they weren't always done inline. It incentivizes programming language authors to squeeze more out of columns, and as a result creates quirky reading that while is more featureful or does things that aren't even possible in other languages, makes for a less than aesthetic reading experience.
I think my opinions can be handwaved away here, but I just wish we as programmers found nicer ways to give these attributes to functions, variables, and parameters.
My account is throttled by Hacker News moderators. So, I can't participate any more here for the time being. Thank you for replying to my comments.
Just expressing some petty opinions, I don't mean to start a syntax flame bait war, sorry all.
Edit (for Ygg2): What you think is superficial is an entire portion of the art of software development. And your usage of FUD is incorrect. Disliking a painting, a song, or a book isn't FUD. It's just plain as day disinterest.
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 the safety of Rust but without it being such a huge shift. Like converting C++ to C#.
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 to profit from business with the Department of War, and maybe fewer individuals will benefit from spinning "Defense" industry as anything other than trade in arms and armor intended for state sanctioned violence. Something about "Defense Industry" just carried a whole lot of "ick" in modern parlance.
(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.)
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 and memory safety in my opinion.
If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language. It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno) and dep hell of Python (which was a nightmare until uv).
If Rust didn’t have the syntax warts (macros), it would be eating the world.
This is C to Rust, not C++ to Rust. That's important.
DARPA was willing to award multiple contracts, but the only one awarded is to a group from several universities. [1]
"The team’s approach, Formally-Verified Compositional Lifting of C to Rust (which forms the acronym ForCLift, pronounced “forklift”), uses Verified Lifting, which combines formal methods and program analysis with AI techniques such as Large Language Models, so as to create accurate translations of complex C code into safe, idiomatic Rust. The approach seeks to enable formal verification of the translated code while also preserving performance-critical behavior."
This involves something called "Verified Lifting."[2] "Metalift uses verified lifting to search for possible candidate programs in the target language that the given input can be translated to." So it's looking for matching idioms in the target language and using proof techniques to check that they are equivalent. Going uphill in abstraction automatically is rare. This will definitely be interesting.
It's essential to good translation.
The old C2Rust is all downhill. What comes out of C2Rust are huge numbers of calls to functions that exactly emulate C semantics, bugs and all. I tried it once, on a buggy JPEG 2000 decoder. The test case which caused a segfault in the C version also caused a segfault in the unsafe Rust version. At least it generates compatible code.
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.
15 comments
[ 4.8 ms ] story [ 37.8 ms ] threadTo 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 silent failure through invalid data, not crashing.
I'm impressed that the language is even uglier than bad C++, which is an accomplishment in violating the beauty of reading.
Edit:
No, I think complicated C++ is also distasteful, but equally, sometimes both are just simply necessary.
Annotating specific attributes of data flow is just a requirement for types of guarantees, but I wish they weren't always done inline. It incentivizes programming language authors to squeeze more out of columns, and as a result creates quirky reading that while is more featureful or does things that aren't even possible in other languages, makes for a less than aesthetic reading experience.
I think my opinions can be handwaved away here, but I just wish we as programmers found nicer ways to give these attributes to functions, variables, and parameters.
My account is throttled by Hacker News moderators. So, I can't participate any more here for the time being. Thank you for replying to my comments.
Just expressing some petty opinions, I don't mean to start a syntax flame bait war, sorry all.
Edit (for Ygg2): What you think is superficial is an entire portion of the art of software development. And your usage of FUD is incorrect. Disliking a painting, a song, or a book isn't FUD. It's just plain as day disinterest.
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 the safety of Rust but without it being such a huge shift. Like converting C++ to C#.
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 to profit from business with the Department of War, and maybe fewer individuals will benefit from spinning "Defense" industry as anything other than trade in arms and armor intended for state sanctioned violence. Something about "Defense Industry" just carried a whole lot of "ick" in modern parlance.
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.)
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 and memory safety in my opinion.
If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language. It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno) and dep hell of Python (which was a nightmare until uv).
If Rust didn’t have the syntax warts (macros), it would be eating the world.
Soon LLMs will be able to write Fortran in any language!
DARPA was willing to award multiple contracts, but the only one awarded is to a group from several universities. [1]
"The team’s approach, Formally-Verified Compositional Lifting of C to Rust (which forms the acronym ForCLift, pronounced “forklift”), uses Verified Lifting, which combines formal methods and program analysis with AI techniques such as Large Language Models, so as to create accurate translations of complex C code into safe, idiomatic Rust. The approach seeks to enable formal verification of the translated code while also preserving performance-critical behavior."
This involves something called "Verified Lifting."[2] "Metalift uses verified lifting to search for possible candidate programs in the target language that the given input can be translated to." So it's looking for matching idioms in the target language and using proof techniques to check that they are equivalent. Going uphill in abstraction automatically is rare. This will definitely be interesting. It's essential to good translation.
The old C2Rust is all downhill. What comes out of C2Rust are huge numbers of calls to functions that exactly emulate C semantics, bugs and all. I tried it once, on a buggy JPEG 2000 decoder. The test case which caused a segfault in the C version also caused a segfault in the unsafe Rust version. At least it generates compatible code.
[1] https://www.cs.wisc.edu/2025/07/15/translating-legacy-code-f...
[2] https://metalift.pages.dev/
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?