10 ms·

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

136 points by alhazraed 1y ago

andrewmcwatters 1y ago
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.
- synack 1y ago
  Have you tried Ada?
  - andrewmcwatters 1y ago
    No, though I am familiar with its history a bit.
  - ggm 1y ago
    Wait, wasn't there a DARPA round funding automatic translation of C to Ada once, long ago?
- mikepurvis 1y ago
  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 that way the “ugliness” is really just a manifestation of “hard things possible” and the language not hiding the underlying realities from you.
  - andrewmcwatters 1y ago
    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 that explicit nature is defined elsewhere rather than reading like a compact run-on sentence. (I'm hypocritically writing here, since I do this too often myself.)
    - mynameisash 1y ago
      > 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?
      - mikepurvis 1y ago
        As in the prior comment, I'm a relative novice myself and certainly never achieved that moment with Rust where the code kind of melts away and you just see raw intent ("blonde, blunette, redhead"), but I do wonder if languages like Python have set our expectations a bit unrealistically in regards to that. Like instead of prioritizing information density, explicitness, and clarity, we got excited about the quick rush that came with `import antigravity`. Java and C++ aren't just verbose, there's a lot of redundancy there, at least classically. Stuff that is needlessly repeated between headers and implementation, cases where you're having to hold the compiler's hand and continually repeat information that it should be able to infer itself from the code. And then the moment you find auto or template inference and feel like you can finally trust the compiler to do the right thing, it barfs up half a page of inscrutable errors and you're back to babying it. Rust—in my limited exposure—is hitting kind of a sweet spot where it's the expressiveness and build/package ecosystem of Python, the performance and precision of C++, and the density of Perl. Or at least that's what's being aimed for; but obviously these goals open it up to charges that it's actually just as unreadable as Perl or as verbose as C++.
- malwrar 1y ago
  I’d suggest reading their (free, online) book if you haven’t already, that’s what motivated me to actually try using it. It sells its core features pretty well and eased me into it better than just trying to grok the syntax. What kept me using it is how annoyingly frequently my code would _just work_ once I got it compiling, which I could often get to pretty quickly by catching errors early with a linter. I’d highly recommend giving it an honest try, the aesthetics make sense with a minimal amount of experience.
  - andrewmcwatters 1y ago
    I am definitely interested in working with it more. It's obviously a fantastic modern language. It just has warts to me. Ones that make learning it a little off-putting in specific domains. I mostly expose myself to it, at the moment, through benchmark work which highlights how competitive of a good language it is.
  - adastra22 1y ago
    As we transition to an era of LLM-generated code, it also means that once the LLM gets it to compile, it likely works.
- School-Cotton 1y ago
  I see this complaint all the time about Rust, and it always confuses me because it doesn't match my experience at all. Do you have an example of Rust syntax that is more complicated than complicated C++?
- geertj 1y ago
  It’s sad you are getting downvoted for simply expressing what seems to be a genuine opinion.
  - andrewmcwatters 1y ago
    I am getting tired of participating in this community for many reasons, but this specific reason is one of the most tiring ones. But there's seemingly nowhere else to go, but maybe small Discord servers where you can meet people and share honest opinions that are real and agree to disagree without penalty. Everyone should feel free to express harmless opinions. Edit: Whoever downvoted me for this comment is proving my point. Edit (for adastra22): I'm not sure that me providing a list of specific modifications to Rust syntax is meaningful to anyone anyway. I'm just a nobody. And it should be OK for people to express personal opinions that hint towards something being wrong without also being required to solve the problem. That's just life.
    - adastra22 1y ago
      I didn’t downvote you, but I can see why your original unedited comment was downvoted. It provided no actionable objections, e.g. no examples.
  - Ygg2 1y ago
    Because it's an extremely subjective, extremely superficial statement that does more FUD than it explains.
- scoopdewoop 1y ago
  I once had a boss that used to really hate python. He would roll his eyes whenever it was brought up. He was CTO of the company and he would sneer at it. One day, in a one-to-one meeting, I asked him, "what is so bad about python?" I expected him to explain some core deficiencies: problems regarding the module system or multi-threading limitations, or some pathological case where latency spikes... and he said "I don't like the whitespace." I never took him seriously again and left that company shortly after.
  - hn_acc1 1y ago
    I mean, I don't work with python all the time, but at work, it's the #2 language.. And the whitespace stuff is the most annoying part of it by far.
- pizlonator 1y ago
  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 that it’s either not possible to do it any other way or that you get a worse outcome if you do it another way. The cyclic nature of compiler IRs comes to mind. As do the wacky relationships between objects in games. Complex uses of syscall ABI are another. Oh and dynamic linking. Likely there are many other examples. The idea that an LLM would convert C to Rust without introducing a slew of problems along the way is especially juvenile. Most likely the LLM with either use the unsafe subset of Rust, or produce Rust code that doesn’t actually match the functionality of the C code (but declare premature victory thinking that it did).
  - adastra22 1y ago
    Do you have specific examples? All the areas you list are done in Rust too, where the borrow checker helps make sure they are bug free. Do you have an example of something that just can’t be represented in Rust’s type system?
  - AlotOfReading 1y ago
    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.
  - Havoc 1y ago
    This is DARPA we're talking about. They've got a pretty good track record on pulling off stuff people we're convinced can't be done
- adastra22 1y ago
  I don’t consider Rust beautiful, but after a decade of working with Rust I am no longer bothered by its aesthetic warts.
- Ygg2 1y ago
  > My account is throttled by Hacker News moderators. Seems most accounts are throttled 2posts per hour. Mine included. > 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. There is no art in programming language design. Art can be defined as something meant to exist solely for its own sake. That's not what PL is. It's just the thing that makes up a program. There is a lot of creativity and application involved in programming language design. You can design works of art with a language. But on its own I would have trouble seeing it as art. But what you mean by art is probably aesthetic i.e. how beautiful is something to look at. When it down comes to userbase it's just a popularity contest. Braces, Parens, keyword or indent? It makes very little difference. Yet people are vocal about their pet syntax being "The one true" syntax to rule them all. It's like quarreling over whether to stir cement clockwise or counterclockwise. I'm of the Douglas Crockford school of language design. Languages are meant to facilitate transfer of programming ideas while minimizing errors. If your syntax isn't minimizing errors I frankly don't give a damn. Give me a cement that lasts a thousand years, not one with that I need to worry which way I mix. As for FUD, I stand by that statement. Saying Rust is uglier than C++ a language known for its near-universally disliked syntax definitely strikes me sowing fear aimed at newcommers.
bangaladore 1y ago
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#.
- adastra22 1y ago
  Examples?
  - pizlonator 1y ago
    Doubly linked lists. Any cyclic data structure.
    - hackyhacky 1y ago
      Both of those are a direct consequence of Rust's memory model, not a result of animus against C++.
    - JoshTriplett 1y ago
      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.)
      - pizlonator 1y ago
        Ref counting doesn’t work for cyclic data structures
        JoshTriplett 1y ago
        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.
observationist 1y ago
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.
- cozzyd 1y ago
  Wait until Hegseth learns about the "safety" ethos present in rust and how heavy the binaries can be.
- hobs 1y ago
  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.
- kspacewalk2 1y ago
  What alternative to having a defense/war industry and stockpiling significant amounts of armour and arms intended for state sanctioned violence do you propose? Where do the actions of the current governments of the PRC, Russia and North Korea figure in this proposed setup? What do you think the consequences of the transition phase (not the final result) of your changes will be? Some possible quantifiable measures of the latter include number of additional wars fought, number of additional genocides perpetrated, number of additional millions killed in conflict; but you're free to choose your own.
  - observationist 1y ago
    Oh, no alternative proposed. The US has lost 10+ trillion to what amounts to an unaccountable budgetary black hole, however, and limiting the awful dingleberry NGOs and private contractors and horde of companies and people that exploit the need for miltary R&D is a good thing. The US should definitely keep doing R&D, the tech that comes out of DARPA has lots of downstream benefits beyond military applications. We should continue producing the best tech in the world, and explore all sorts of skunkworks and moonshots and crazy tinkering. I agree with "peace through strength" - be too dangerous to abuse, and if shit goes down, be the one who decides who wins and loses. We don't need a corrupt military industrial complex, endless wars, private contractors, NGOs, nepo-grifters, and all the rabble that have abused the lack of accountability to make themselves rich, or inflict unrest on other countries, or manipulate bureaucracy for political gain, and all that jazz. Basic things like "department of war" naming fall in that direction, from my perspective. Simplify, cut, use blunt truthful language, and figure out how to hold them accountable going forward, at the very least, and at best, figure out how to claw back the trillions, or figure out where it went. You don't need to alter the underlying mission at all, really. See, there's this notion that the US is a bad guy, and they point out all the casualties and conflicts and collateral damage and say "see, we're the baddies!" They never account for the context. Some of it is as simple as pointing out that if we hadn't killed all those german nazis, and sought pacifism and peace at any price, we'd all be speaking German. Some legitimate atrocities have occurred, as recently as Obama's unnecessary drone murders, but ranging from improper harms done to US troops, exposure to toxins, Abu Ghraib abuses of civil liberties, some of what's happened at Gitmo, etc. Each and every time we recognize a harm done, we should at the very least hold ourselves, collectively, responsible, and seek to be better. Accountability is a civic duty, regardless of political affiliation or philosophy. We should also be honest about necessary evils, not allow ourselves to be manipulated by bad faith actors, back up positions and words with actions and force, and hold ourselves to the highest possible standards. If we find ourselves continuously presented with no alternatives except between two evils, we should choose the lesser evil which allows us to preserve ourselves (otherwise, what are we even doing?) The US body politic has allowed assumptions of good faith by our bureaucrats and military brass and politicians to fester into unimaginable corruption and vice, proving Eisenhower a prophet. We should simply be better - little things, important things, ground up discipline, principles, and a persisted social construct upon which to stably build a nation's strength is 100% necessary. A lot of what Trump and Hegseth are doing pushes in that direction. Some aspirational, some performative, some well intentioned but wrong, but I think it's mostly in good faith, and I can get behind that. I wish more on the left would at a bare minimum wish everyone to be responsible and to do well, for everyone to be happy, healthy, prosperous, and free. It has to be permitted to hope that whoever is in power achieves victories and success in those basic things, or we've lost the plot.
pizlonator 1y ago
(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.)
- NobodyNada 1y ago
  > 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. This is half of it; the other half is that there's more to writing correct code than just memory safety. Rust was not initially designed as a memory-safe "C alternative" -- it started as a higher level language with green threading and garbage collection. Borrow checking, affine types, and all that were introduced not to "solve" memory safety, but to reduce logic bugs in complex, highly concurrent code by enabling programmers to statically check application invariants using the type system. Once it became apparent that this system was powerful enough to express the semantics of full memory safety without garbage collection, GC was removed from the core of the language, and Rust became what it looks like now. The point is, I think focusing on "memory safety" seriously undersells Rust. Rust is aimed at giving you tools to statically verify arbitrary correctness properties of your program; and memory safety is just one example of how the standard library uses the available tooling to prove one particularly useful property. But Rust's "safety" protects you from any logic bug that you define to be a safety issue. Additionally, this means that you're not restricted to one particular runtime or environment's ideas of memory safety -- you can write or bring in unsafe code to define your own requirements. This is very important to me -- I work on low-level driver and RTOS code for microcontrollers, and am commonly doing very unsafe things with task switching, interrupts, DMA, memory layout and pointer casting tricks, inline assembly, hardware MMIO, power management, etc. Rust fits fantastically in this niche, because I can use the type system to write out all the preconditions that external users must uphold when interacting with my driver code. I think Fil-C is an excellent project, and is far more practical and realistic than TRACTOR for the problem of securing legacy code. But I also see it as largely orthogonal to Rust -- I can't see many situations where someone would choose Fil-C for greenfield code over something like Java or Go. Rust has safety, performance, and interop advantages over GC'd languages; and safety advantages over other C-like languages; so it's a great choice for new projects, but it's not gonna help you with all your old code like Fil-C will. > It’s also annoying that this DARPA page mentions some kind of consensus. There’s no consensus on Rust being the safe bet. The "consensus" the article talks about is not Rust, it's that "relying on bug-finding tools is not enough." Swift, C++-with-[the right]-changes, and Fil-C all would fall within that consensus (of needing some sort of guaranteed safety); only Zig is something of an exception in your list.
IceHegel 1y ago
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.
- foota 1y ago
  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.
  - the__alchemist 1y ago
    I'm confused too! When I write Python, I do it in a similar style as rust, but knowing the classes and enums are sloppier than rust's; regarding mutation for example.
  - AnimalMuppet 1y ago
    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 surface area where the bug can be is much smaller. The bigger the code base and the more well-used the class is, the more this matters.
    - foota 1y ago
ironfootnz 1y ago
I think the only folks can solve this at the guys at autohand.ai They're into something at this level.
scj 1y ago
Is it going to translate C into good Rust code, or just C with a Rust accent? Think transpiled C in Javascript. Soon LLMs will be able to write Fortran in any language!
- tialaramex 1y ago
  There are definitely categories of code where you could realistically expect lift-and-shift from C which you're confident is correct to safe Rust that's maybe not very idiomatic but understandable. I believe Microsoft has a tool which did this for some bit twiddling crypto code. They have high confidence their C crypto code is correct, they run a process, they get safe Rust, and so their confidence transfers but now it's safe Rust so it just works in Rust software and you get all their existing confidence. But it's never going to be all code, and it might well never be most code.
joshcsimmons 1y ago
Rust is the ideal language for defense applications. It's great to see defense buxxx funding this transition.
pyuser583 1y ago
I've said it before, but C with proper tooling extremely safe.
- waterTanuki 1y ago
  Every time this subject comes up there is always a "well MY C code is safe so Rust is a stupid language! You're just using the <language wrong/wrong tools>". I find it funny how much folks foam at the mouth about using X or Y wrong in a language that specifically chose to be flexible to fit into any possible combinations of toolsets and now you're telling people they need to use YOUR tools. Meanwhile Rust has solved this problem by having 1 compiler, 1 package manager, 1 formatter, 1 way to run tests, etc. etc. C/C++ will never have this because of how fragmented the ecosystem is. That's the price paid over years of committee decisions which prioritized industry customization & backwards compatibility above all else. You cannot have your cake and eat it too.
- dymk 1y ago
  You can say it as many times as you want, but we know it’s not true.
- 01HNNWZ0MV43FF 1y ago
  C and C++ yearn for modern tooling equivalent to Cargo and UV Noobs need consensus and senior devs need something that works, supports everything, and runs on crap platforms that can't run a Mix dev shell (Windows)
- nickpsecurity 1y ago
  Could you list the tooling that you use?
gdiamos 1y ago
They should make the challenge to translate all of Linux and then maintain it
brendank310 1y ago
Past work in the area by the folks at Immunant (https://immunant.com/ https://immunant.com/) that appears to be on-going https://github.com/immunant/c2rust https://github.com/immunant/c2rust. I think the project was also DARPA funded for a time.
ChrisArchitect 1y ago
More discussion last year: https://news.ycombinator.com/item?id=41110269 https://news.ycombinator.com/item?id=41110269
Animats 1y ago
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. [1] https://www.cs.wisc.edu/2025/07/15/translating-legacy-code-for-a-safer-future/ https://www.cs.wisc.edu/2025/07/15/translating-legacy-code-f... [2] https://metalift.pages.dev/ https://metalift.pages.dev/
- juliangmp 1y ago
  > 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. I mean... That's what I would expect. It's a translation not a rewrite. The question here is really “what's the end goal?”. Are you gonna refactor parts of the translations output, or is that too much work? Cause a pure translation won't give you anything besides a different compiler and build system. Ah well I guess you can claim you're memory safe and blazingly fast
  - estebank 1y ago
    There's one reason I could think of for translating from C to Rust without further changes: simplifying the build. If you can remove the need for a build.rs script running make, that's one headache less. At that point you have exactly the same behaviour as wrapping the original C code in a -sys crate, so all of the usual caveats are warranted.
iberator 1y ago
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?
- correct_horse 1y ago
  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.

136 points by alhazraed 1y ago

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.

synack 1y ago
Have you tried Ada?
- andrewmcwatters 1y ago
  No, though I am familiar with its history a bit.
- ggm 1y ago
  Wait, wasn't there a DARPA round funding automatic translation of C to Ada once, long ago?
mikepurvis 1y ago
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 that way the “ugliness” is really just a manifestation of “hard things possible” and the language not hiding the underlying realities from you.
- andrewmcwatters 1y ago
  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 that explicit nature is defined elsewhere rather than reading like a compact run-on sentence. (I'm hypocritically writing here, since I do this too often myself.)
  - mynameisash 1y ago
    > 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?
    - mikepurvis 1y ago
      As in the prior comment, I'm a relative novice myself and certainly never achieved that moment with Rust where the code kind of melts away and you just see raw intent ("blonde, blunette, redhead"), but I do wonder if languages like Python have set our expectations a bit unrealistically in regards to that. Like instead of prioritizing information density, explicitness, and clarity, we got excited about the quick rush that came with `import antigravity`. Java and C++ aren't just verbose, there's a lot of redundancy there, at least classically. Stuff that is needlessly repeated between headers and implementation, cases where you're having to hold the compiler's hand and continually repeat information that it should be able to infer itself from the code. And then the moment you find auto or template inference and feel like you can finally trust the compiler to do the right thing, it barfs up half a page of inscrutable errors and you're back to babying it. Rust—in my limited exposure—is hitting kind of a sweet spot where it's the expressiveness and build/package ecosystem of Python, the performance and precision of C++, and the density of Perl. Or at least that's what's being aimed for; but obviously these goals open it up to charges that it's actually just as unreadable as Perl or as verbose as C++.
malwrar 1y ago
I’d suggest reading their (free, online) book if you haven’t already, that’s what motivated me to actually try using it. It sells its core features pretty well and eased me into it better than just trying to grok the syntax. What kept me using it is how annoyingly frequently my code would _just work_ once I got it compiling, which I could often get to pretty quickly by catching errors early with a linter. I’d highly recommend giving it an honest try, the aesthetics make sense with a minimal amount of experience.
- andrewmcwatters 1y ago
  I am definitely interested in working with it more. It's obviously a fantastic modern language. It just has warts to me. Ones that make learning it a little off-putting in specific domains. I mostly expose myself to it, at the moment, through benchmark work which highlights how competitive of a good language it is.
- adastra22 1y ago
  As we transition to an era of LLM-generated code, it also means that once the LLM gets it to compile, it likely works.
School-Cotton 1y ago
I see this complaint all the time about Rust, and it always confuses me because it doesn't match my experience at all. Do you have an example of Rust syntax that is more complicated than complicated C++?
geertj 1y ago
It’s sad you are getting downvoted for simply expressing what seems to be a genuine opinion.
- andrewmcwatters 1y ago
  I am getting tired of participating in this community for many reasons, but this specific reason is one of the most tiring ones. But there's seemingly nowhere else to go, but maybe small Discord servers where you can meet people and share honest opinions that are real and agree to disagree without penalty. Everyone should feel free to express harmless opinions. Edit: Whoever downvoted me for this comment is proving my point. Edit (for adastra22): I'm not sure that me providing a list of specific modifications to Rust syntax is meaningful to anyone anyway. I'm just a nobody. And it should be OK for people to express personal opinions that hint towards something being wrong without also being required to solve the problem. That's just life.
  - adastra22 1y ago
    I didn’t downvote you, but I can see why your original unedited comment was downvoted. It provided no actionable objections, e.g. no examples.
- Ygg2 1y ago
  Because it's an extremely subjective, extremely superficial statement that does more FUD than it explains.
scoopdewoop 1y ago
I once had a boss that used to really hate python. He would roll his eyes whenever it was brought up. He was CTO of the company and he would sneer at it. One day, in a one-to-one meeting, I asked him, "what is so bad about python?" I expected him to explain some core deficiencies: problems regarding the module system or multi-threading limitations, or some pathological case where latency spikes... and he said "I don't like the whitespace." I never took him seriously again and left that company shortly after.
- hn_acc1 1y ago
  I mean, I don't work with python all the time, but at work, it's the #2 language.. And the whitespace stuff is the most annoying part of it by far.
pizlonator 1y ago
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 that it’s either not possible to do it any other way or that you get a worse outcome if you do it another way. The cyclic nature of compiler IRs comes to mind. As do the wacky relationships between objects in games. Complex uses of syscall ABI are another. Oh and dynamic linking. Likely there are many other examples. The idea that an LLM would convert C to Rust without introducing a slew of problems along the way is especially juvenile. Most likely the LLM with either use the unsafe subset of Rust, or produce Rust code that doesn’t actually match the functionality of the C code (but declare premature victory thinking that it did).
- adastra22 1y ago
  Do you have specific examples? All the areas you list are done in Rust too, where the borrow checker helps make sure they are bug free. Do you have an example of something that just can’t be represented in Rust’s type system?
- AlotOfReading 1y ago
  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.
- Havoc 1y ago
  This is DARPA we're talking about. They've got a pretty good track record on pulling off stuff people we're convinced can't be done
adastra22 1y ago
I don’t consider Rust beautiful, but after a decade of working with Rust I am no longer bothered by its aesthetic warts.
Ygg2 1y ago
> My account is throttled by Hacker News moderators. Seems most accounts are throttled 2posts per hour. Mine included. > 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. There is no art in programming language design. Art can be defined as something meant to exist solely for its own sake. That's not what PL is. It's just the thing that makes up a program. There is a lot of creativity and application involved in programming language design. You can design works of art with a language. But on its own I would have trouble seeing it as art. But what you mean by art is probably aesthetic i.e. how beautiful is something to look at. When it down comes to userbase it's just a popularity contest. Braces, Parens, keyword or indent? It makes very little difference. Yet people are vocal about their pet syntax being "The one true" syntax to rule them all. It's like quarreling over whether to stir cement clockwise or counterclockwise. I'm of the Douglas Crockford school of language design. Languages are meant to facilitate transfer of programming ideas while minimizing errors. If your syntax isn't minimizing errors I frankly don't give a damn. Give me a cement that lasts a thousand years, not one with that I need to worry which way I mix. As for FUD, I stand by that statement. Saying Rust is uglier than C++ a language known for its near-universally disliked syntax definitely strikes me sowing fear aimed at newcommers.

bangaladore 1y ago

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

adastra22 1y ago
Examples?
- pizlonator 1y ago
  Doubly linked lists. Any cyclic data structure.
  - hackyhacky 1y ago
    Both of those are a direct consequence of Rust's memory model, not a result of animus against C++.
  - JoshTriplett 1y ago
    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.)
    - pizlonator 1y ago
      Ref counting doesn’t work for cyclic data structures
      - JoshTriplett 1y ago
        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.

observationist 1y ago

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.

cozzyd 1y ago
Wait until Hegseth learns about the "safety" ethos present in rust and how heavy the binaries can be.
hobs 1y ago
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.
kspacewalk2 1y ago
What alternative to having a defense/war industry and stockpiling significant amounts of armour and arms intended for state sanctioned violence do you propose? Where do the actions of the current governments of the PRC, Russia and North Korea figure in this proposed setup? What do you think the consequences of the transition phase (not the final result) of your changes will be? Some possible quantifiable measures of the latter include number of additional wars fought, number of additional genocides perpetrated, number of additional millions killed in conflict; but you're free to choose your own.
- observationist 1y ago
  Oh, no alternative proposed. The US has lost 10+ trillion to what amounts to an unaccountable budgetary black hole, however, and limiting the awful dingleberry NGOs and private contractors and horde of companies and people that exploit the need for miltary R&D is a good thing. The US should definitely keep doing R&D, the tech that comes out of DARPA has lots of downstream benefits beyond military applications. We should continue producing the best tech in the world, and explore all sorts of skunkworks and moonshots and crazy tinkering. I agree with "peace through strength" - be too dangerous to abuse, and if shit goes down, be the one who decides who wins and loses. We don't need a corrupt military industrial complex, endless wars, private contractors, NGOs, nepo-grifters, and all the rabble that have abused the lack of accountability to make themselves rich, or inflict unrest on other countries, or manipulate bureaucracy for political gain, and all that jazz. Basic things like "department of war" naming fall in that direction, from my perspective. Simplify, cut, use blunt truthful language, and figure out how to hold them accountable going forward, at the very least, and at best, figure out how to claw back the trillions, or figure out where it went. You don't need to alter the underlying mission at all, really. See, there's this notion that the US is a bad guy, and they point out all the casualties and conflicts and collateral damage and say "see, we're the baddies!" They never account for the context. Some of it is as simple as pointing out that if we hadn't killed all those german nazis, and sought pacifism and peace at any price, we'd all be speaking German. Some legitimate atrocities have occurred, as recently as Obama's unnecessary drone murders, but ranging from improper harms done to US troops, exposure to toxins, Abu Ghraib abuses of civil liberties, some of what's happened at Gitmo, etc. Each and every time we recognize a harm done, we should at the very least hold ourselves, collectively, responsible, and seek to be better. Accountability is a civic duty, regardless of political affiliation or philosophy. We should also be honest about necessary evils, not allow ourselves to be manipulated by bad faith actors, back up positions and words with actions and force, and hold ourselves to the highest possible standards. If we find ourselves continuously presented with no alternatives except between two evils, we should choose the lesser evil which allows us to preserve ourselves (otherwise, what are we even doing?) The US body politic has allowed assumptions of good faith by our bureaucrats and military brass and politicians to fester into unimaginable corruption and vice, proving Eisenhower a prophet. We should simply be better - little things, important things, ground up discipline, principles, and a persisted social construct upon which to stably build a nation's strength is 100% necessary. A lot of what Trump and Hegseth are doing pushes in that direction. Some aspirational, some performative, some well intentioned but wrong, but I think it's mostly in good faith, and I can get behind that. I wish more on the left would at a bare minimum wish everyone to be responsible and to do well, for everyone to be happy, healthy, prosperous, and free. It has to be permitted to hope that whoever is in power achieves victories and success in those basic things, or we've lost the plot.

pizlonator 1y ago

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

NobodyNada 1y ago
> 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. This is half of it; the other half is that there's more to writing correct code than just memory safety. Rust was not initially designed as a memory-safe "C alternative" -- it started as a higher level language with green threading and garbage collection. Borrow checking, affine types, and all that were introduced not to "solve" memory safety, but to reduce logic bugs in complex, highly concurrent code by enabling programmers to statically check application invariants using the type system. Once it became apparent that this system was powerful enough to express the semantics of full memory safety without garbage collection, GC was removed from the core of the language, and Rust became what it looks like now. The point is, I think focusing on "memory safety" seriously undersells Rust. Rust is aimed at giving you tools to statically verify arbitrary correctness properties of your program; and memory safety is just one example of how the standard library uses the available tooling to prove one particularly useful property. But Rust's "safety" protects you from any logic bug that you define to be a safety issue. Additionally, this means that you're not restricted to one particular runtime or environment's ideas of memory safety -- you can write or bring in unsafe code to define your own requirements. This is very important to me -- I work on low-level driver and RTOS code for microcontrollers, and am commonly doing very unsafe things with task switching, interrupts, DMA, memory layout and pointer casting tricks, inline assembly, hardware MMIO, power management, etc. Rust fits fantastically in this niche, because I can use the type system to write out all the preconditions that external users must uphold when interacting with my driver code. I think Fil-C is an excellent project, and is far more practical and realistic than TRACTOR for the problem of securing legacy code. But I also see it as largely orthogonal to Rust -- I can't see many situations where someone would choose Fil-C for greenfield code over something like Java or Go. Rust has safety, performance, and interop advantages over GC'd languages; and safety advantages over other C-like languages; so it's a great choice for new projects, but it's not gonna help you with all your old code like Fil-C will. > It’s also annoying that this DARPA page mentions some kind of consensus. There’s no consensus on Rust being the safe bet. The "consensus" the article talks about is not Rust, it's that "relying on bug-finding tools is not enough." Swift, C++-with-[the right]-changes, and Fil-C all would fall within that consensus (of needing some sort of guaranteed safety); only Zig is something of an exception in your list.

IceHegel 1y ago

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.

foota 1y ago
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.
- the__alchemist 1y ago
  I'm confused too! When I write Python, I do it in a similar style as rust, but knowing the classes and enums are sloppier than rust's; regarding mutation for example.
- AnimalMuppet 1y ago
  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 surface area where the bug can be is much smaller. The bigger the code base and the more well-used the class is, the more this matters.
  - foota 1y ago

ironfootnz 1y ago

I think the only folks can solve this at the guys at autohand.ai They're into something at this level.

scj 1y ago

Is it going to translate C into good Rust code, or just C with a Rust accent? Think transpiled C in Javascript. Soon LLMs will be able to write Fortran in any language!

tialaramex 1y ago
There are definitely categories of code where you could realistically expect lift-and-shift from C which you're confident is correct to safe Rust that's maybe not very idiomatic but understandable. I believe Microsoft has a tool which did this for some bit twiddling crypto code. They have high confidence their C crypto code is correct, they run a process, they get safe Rust, and so their confidence transfers but now it's safe Rust so it just works in Rust software and you get all their existing confidence. But it's never going to be all code, and it might well never be most code.

joshcsimmons 1y ago

Rust is the ideal language for defense applications. It's great to see defense buxxx funding this transition.

pyuser583 1y ago

I've said it before, but C with proper tooling extremely safe.

waterTanuki 1y ago
Every time this subject comes up there is always a "well MY C code is safe so Rust is a stupid language! You're just using the <language wrong/wrong tools>". I find it funny how much folks foam at the mouth about using X or Y wrong in a language that specifically chose to be flexible to fit into any possible combinations of toolsets and now you're telling people they need to use YOUR tools. Meanwhile Rust has solved this problem by having 1 compiler, 1 package manager, 1 formatter, 1 way to run tests, etc. etc. C/C++ will never have this because of how fragmented the ecosystem is. That's the price paid over years of committee decisions which prioritized industry customization & backwards compatibility above all else. You cannot have your cake and eat it too.
dymk 1y ago
You can say it as many times as you want, but we know it’s not true.
01HNNWZ0MV43FF 1y ago
C and C++ yearn for modern tooling equivalent to Cargo and UV Noobs need consensus and senior devs need something that works, supports everything, and runs on crap platforms that can't run a Mix dev shell (Windows)
nickpsecurity 1y ago
Could you list the tooling that you use?

gdiamos 1y ago

They should make the challenge to translate all of Linux and then maintain it

brendank310 1y ago

Past work in the area by the folks at Immunant (https://immunant.com/ https://immunant.com/) that appears to be on-going https://github.com/immunant/c2rust https://github.com/immunant/c2rust. I think the project was also DARPA funded for a time.

ChrisArchitect 1y ago

More discussion last year: https://news.ycombinator.com/item?id=41110269 https://news.ycombinator.com/item?id=41110269

Animats 1y ago

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. [1] https://www.cs.wisc.edu/2025/07/15/translating-legacy-code-for-a-safer-future/ https://www.cs.wisc.edu/2025/07/15/translating-legacy-code-f... [2] https://metalift.pages.dev/ https://metalift.pages.dev/

juliangmp 1y ago
> 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. I mean... That's what I would expect. It's a translation not a rewrite. The question here is really “what's the end goal?”. Are you gonna refactor parts of the translations output, or is that too much work? Cause a pure translation won't give you anything besides a different compiler and build system. Ah well I guess you can claim you're memory safe and blazingly fast
- estebank 1y ago
  There's one reason I could think of for translating from C to Rust without further changes: simplifying the build. If you can remove the need for a build.rs script running make, that's one headache less. At that point you have exactly the same behaviour as wrapping the original C code in a -sys crate, so all of the usual caveats are warranted.

iberator 1y ago

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?

correct_horse 1y ago
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.