[HN Gopher] DARPA project for automated translation from C to Ru...
___________________________________________________________________
DARPA project for automated translation from C to Rust (2024)
Author : alhazraed
Score : 54 points
Date : 2025-10-01 20:53 UTC (2 hours ago)
(HTM) web link (www.darpa.mil)
(TXT) w3m dump (www.darpa.mil)
| andrewmcwatters wrote:
| 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 wrote:
| Have you tried Ada?
| andrewmcwatters wrote:
| No, though I am familiar with its history a bit.
| ggm wrote:
| Wait, wasn't there a DARPA round funding automatic
| translation of C to Ada once, long ago?
| mikepurvis wrote:
| 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 wrote:
| 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 wrote:
| > 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?
| malwrar wrote:
| 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 wrote:
| 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 wrote:
| As we transition to an era of LLM-generated code, it also
| means that once the LLM gets it to compile, it likely works.
| umanwizard wrote:
| 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 wrote:
| It's sad you are getting downvoted for simply expressing what
| seems to be a genuine opinion.
| andrewmcwatters wrote:
| 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 wrote:
| 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 wrote:
| Because it's an extremely subjective, extremely superficial
| statement that does more FUD than it explains.
| scoopdewoop wrote:
| 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.
| pizlonator wrote:
| 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 wrote:
| 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 wrote:
| 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.
| adastra22 wrote:
| I don't consider Rust beautiful, but after a decade of working
| with Rust I am no longer bothered by its aesthetic warts.
| bangaladore wrote:
| 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 wrote:
| Examples?
| pizlonator wrote:
| Doubly linked lists. Any cyclic data structure.
| hackyhacky wrote:
| Both of those are a direct consequence of Rust's memory
| model, not a result of animus against C++.
| JoshTriplett wrote:
| 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 wrote:
| Ref counting doesn't work for cyclic data structures
| JoshTriplett wrote:
| 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.
| NobodyNada wrote:
| Sure it does. Make the backreferences weak, or use a
| library that provides cycle detection (or even full-on
| tracing GC if you really want).
| pizlonator wrote:
| That changes the semantics. It won't work for a graph for
| example.
| adastra22 wrote:
| Rc has downgrade and the Weak type explicitly for this
| purpose.
| jnwatson wrote:
| While I think this is Rust's biggest flaw, this doesn't
| stem from any particular hatred of C/C++. This is related
| to memory safety, as it is very difficult to reason about
| memory lifetimes of object graphs with cycles.
| adastra22 wrote:
| The easiest way to implement these is with Weak references
| in one of the directions. This requires some checking
| and/or locks, but the fact it is not trivial to do is kinda
| the point: the integrity of a cyclic data structure depends
| on managing multiple pointers in multiple structs
| simultaneously, and with that comes concurrency dragons.
| actionfromafar wrote:
| Syntax is different any many places for no apparent reason
| bangaladore wrote:
| 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
| convolvatron wrote:
| 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.
| bangaladore wrote:
| 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.
| Ygg2 wrote:
| > 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++
|
| Sure, so does legible Brainfuck. However, it's extremely
| challenging to write it. It usually takes years and years of
| effort, chasing down obscure bugs.
|
| > Like converting C++ to C#.
|
| If you can take GC pause and not wince, sure, go for it. Not
| everyone can take that luxury.
| the__alchemist wrote:
| Unfortunately, I don't think that's avoidable. This is
| equivalent to lamenting not being able to use Haskell-style
| pure FP, nor object inheritance. There are C++ (and C) design
| patterns that will just not work in rust, or won't work in an
| ergonomic way. The solution is to solve the problem in a
| different way.
|
| I will add a #3 to your list: _Make an all-around nice
| language_ I think playing up rust as the _memory-safe language_
| underplays its value.
| observationist wrote:
| 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 wrote:
| Wait until Hegseth learns about the "safety" ethos present in
| rust and how heavy the binaries can be.
| hobs wrote:
| 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 wrote:
| 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.
| k72siqqu wrote:
| This is from 2024. Hegseth would want a language with a
| "warrior ethos", not Rust with its woke developers.
| wmgries wrote:
| It feels more likely they'd shut down DARPA without realizing
| what it is than try to rename it.
| pizlonator wrote:
| (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.)
| adastra22 wrote:
| Does your thing add linear types, borrow checking, and remove
| implicit conversions from C?
| pizlonator wrote:
| Definitely not. Then it wouldn't be a C implementation.
|
| Fil-C is so compatible that I have a Linux userland compiled
| with it https://fil-c.org/pizlix
|
| Think of Fil-C as Java-ifying C an C++
| AlotOfReading wrote:
| There's plenty of reasons to prefer Rust to a memory-safe C.
| For example, I work on safety-critical code. That means that I
| have to review and affirm "This code implements my design".
| Making C memory-safe doesn't make the semantics of all UB
| defined or appropriate.
|
| Safe rust doesn't have UB, and validating unsafe rust isn't
| meaningfully different than doing it for C++, except that it's
| limited to tiny leaf functions with well-defined interfaces
| where a code reviewer can challenge you.
| woodruffw wrote:
| > 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, they want
| memory safety qua language semantics that foreclose on (many,
| if not all) things that _would_ be memory-unsafe.
|
| Or in other words: it's great to be able to effectively be able
| to forklift C onto a managed runtime, but most people really
| want to be able to write code that doesn't crash at all because
| of expressive limits in C's semantics. "Memory safety" is a
| convenient term of art for this.
| IceHegel wrote:
| 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 wrote:
| 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.
| hu3 wrote:
| > If I clone a Rust repo, it's actually easier to compile,
| test, and run the code than any other language.
|
| I beg to differ because Go has a large standard library which
| means less dependencies than Rust on average.
| ironfootnz wrote:
| I think the only folks can solve this at the guys at autohand.ai
| They're into something at this level.
| scj wrote:
| 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!
___________________________________________________________________
(page generated 2025-10-01 23:00 UTC)