DARPA Wants to Automatically Transpile C Code Into Rust - Using AI (theregister.com) 236
America's Defense Department has launched a project "that aims to develop machine-learning tools that can automate the conversion of legacy C code into Rust," reports the Register — with an online event already scheduled later this month for those planning to submit proposals:
The reason to do so is memory safety. Memory safety bugs, such buffer overflows, account for the majority of major vulnerabilities in large codebases. And DARPA's hope [that's the Defense Department's R&D agency] is that AI models can help with the programming language translation, in order to make software more secure. "You can go to any of the LLM websites, start chatting with one of the AI chatbots, and all you need to say is 'here's some C code, please translate it to safe idiomatic Rust code,' cut, paste, and something comes out, and it's often very good, but not always," said Dan Wallach, DARPA program manager for TRACTOR, in a statement. "The research challenge is to dramatically improve the automated translation from C to Rust, particularly for program constructs with the most relevance...."
DARPA's characterization of the situation suggests the verdict on C and C++ has already been rendered. "After more than two decades of grappling with memory safety issues in C and C++, the software engineering community has reached a consensus," the research agency said, pointing to the Office of the National Cyber Director's call to do more to make software more secure. "Relying on bug-finding tools is not enough...."
Peter Morales, CEO of Code Metal, a company that just raised $16.5 million to focus on transpiling code for edge hardware, told The Register the DARPA project is promising and well-timed. "I think [TRACTOR] is very sound in terms of the viability of getting there and I think it will have a pretty big impact in the cybersecurity space where memory safety is already a pretty big conversation," he said.
DARPA's statement had an ambitious headline: "Eliminating Memory Safety Vulnerabilities Once and For All."
"Rust forces the programmer to get things right," said DARPA project manager Wallach. "It can feel constraining to deal with all the rules it forces, but when you acclimate to them, the rules give you freedom. They're like guardrails; once you realize they're there to protect you, you'll become free to focus on more important things."
Code Metal's Morales called the project "a DARPA-hard problem," noting the daunting number of edge cases that might come up. And even DARPA's program manager conceded to the Register that "some things like the Linux kernel are explicitly out of scope, because they've got technical issues where Rust wouldn't fit."
Thanks to long-time Slashdot reader RoccamOccam for sharing the news.
DARPA's characterization of the situation suggests the verdict on C and C++ has already been rendered. "After more than two decades of grappling with memory safety issues in C and C++, the software engineering community has reached a consensus," the research agency said, pointing to the Office of the National Cyber Director's call to do more to make software more secure. "Relying on bug-finding tools is not enough...."
Peter Morales, CEO of Code Metal, a company that just raised $16.5 million to focus on transpiling code for edge hardware, told The Register the DARPA project is promising and well-timed. "I think [TRACTOR] is very sound in terms of the viability of getting there and I think it will have a pretty big impact in the cybersecurity space where memory safety is already a pretty big conversation," he said.
DARPA's statement had an ambitious headline: "Eliminating Memory Safety Vulnerabilities Once and For All."
"Rust forces the programmer to get things right," said DARPA project manager Wallach. "It can feel constraining to deal with all the rules it forces, but when you acclimate to them, the rules give you freedom. They're like guardrails; once you realize they're there to protect you, you'll become free to focus on more important things."
Code Metal's Morales called the project "a DARPA-hard problem," noting the daunting number of edge cases that might come up. And even DARPA's program manager conceded to the Register that "some things like the Linux kernel are explicitly out of scope, because they've got technical issues where Rust wouldn't fit."
Thanks to long-time Slashdot reader RoccamOccam for sharing the news.
Why don't you (Score:5, Interesting)
Re:Why don't you (Score:5, Interesting)
Have that same AI find all the memory bugs in C and fix them, no translation needed.
The goal is to also be able to mitigate against future introduced memory bugs by future changes to the programs. One (very) big effort up front, once, rather than constant review(s) and fixes (unless you fantasize programmers are no longer going to introduce memory safety bugs in future changes).
That all the pieces one would need are not yet ready certainly makes this a DARPA type of challenge.
AI bug check probably to become standard IDE tool (Score:2)
Have that same AI find all the memory bugs in C and fix them, no translation needed.
The goal is to also be able to mitigate against future introduced memory bugs by future changes to the programs.
Run the AI on the new code too.
Won't running an AI bug checker become a standard part of the development process? A standard part of the IDE?
One (very) big effort up front, once, rather than constant review(s) and fixes (unless you fantasize programmers are no longer going to introduce memory safety bugs in future changes).
I doubt it will be a very big effort for long and constant reviews automated while the IDE is sitting there waiting for you to type. Like current syntax checkers.
Re: (Score:3)
it's pretty computationally intensive to do that. if you enforce it from the get-go then you don't need to redesign huge chunks of your code down the road. rust solves the now problem, and it solves it very well
Re: (Score:2)
it's pretty computationally intensive to do that.
By then we'll have ML accelerators in our PCs. Look at the Apple side, even Apple watches have a pretty capable ML accelerator.
Drawbacks will be magically solved in the future (Score:5, Insightful)
By then we'll have ML accelerators in our PCs.
The 90s and 00s call, they want their "By then we'll have super modern compilers(*) with will be insanely good at optimising for VLIW" excessive optimism back.
If your solution relies on some technology being widely available and widely successful, maybe first wait until that technology has actually proven itself.
The jury is still out whether there will be anything useful left once the AI buble bursts [locusmag.com].
(More concretely for the current discussion: currently there is no way to know whether future not-yet-on-the-market hardware will be able to continuously run in the background a future not-yet-even-trained-yet AI model in a way that makes it as practical to use in real time as syntax highlighting(**), yet doesn't kill the laptop's battery budget).
---
(*) in the words of Donald Knuth: "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."
(**) There's a reason why, on home computers, syntax highlighting started really developing in the 16bits microcomputers era, and wasn't widespread on earlier 8bits.
Re: (Score:2)
Re: (Score:3)
...but wouldn't an AI bug solver be useful for a Rust project as much as a C or Python project?
Honestly, anything in this space is likely to be a decent step forward, so I look forward to whatever anyone can come up with. However, if you're clever enough to spot (potential) memory issues in C and can write Rust to do the exact same functionality without the bugs, then you can definitely just highlight where the bugs are in the code. That's universally useful, isn't it? We already have "lint" and static anal
Re: (Score:2)
The goal is to also be able to mitigate against future introduced memory bugs by future changes to the programs.
1) Stop using C memory management, mandate use of STL
2) Turn on bounds checking via the compiler switch (although it's probably on by default these days, so... shrug )
3) Profit
Seems dangerous (Score:2)
Have that same AI find all the memory bugs in C and fix them, no translation needed.
I'm thinking AI fixes to C memory problems have a really good change of introducing new flaws or memory problems.
Transcoding into some safer language does seem like a really good idea. Assuming you can trust the transcoding to be functionally equivalent... maybe the AI would get so good it would transcode over detected C memory problems and try to replicate them in Rust. :-)
Re: Seems dangerous (Score:2)
Agreed, I wouldn't use AI for that.
I'd use an Expert System to scan the software and determine the segment in which memory defects arise. A human programmer can then rework that segment, rerun the Expert System, and repeat until no identifiable defects remain.
Re: (Score:2)
Agreed, I wouldn't use AI for that.
I'd use an Expert System to scan the software and determine the segment in which memory defects arise. A human programmer can then rework that segment, rerun the Expert System, and repeat until no identifiable defects remain.
An expert system is AI in exactly the same sense that deep learning is AI. They are both interesting computational techniques that came out of failed (so far) efforts to create a "general artificial intelligence" and they both end up with real limitations that show that they aren't actually "intelligent". An expert system is nice because it's easier to query for the reasons for it's findings but it's much more limited. You could achieve pretty much the same value by asking the deep learning system to create
Re: (Score:2)
Re: (Score:2)
This is the sort of comment that belies a real non-expertise in either language.
Re: Why don't you (Score:2)
In theory, that is possible.
There are ways to validate C against formal mathematical theorems, so you can, in princple, mathematically prove a C program to be free of memory defects, and thus mathematically prove when an arc contains such a defect.
Further, you can easily write a program for identifying when a memory pointer is lost, which ergo tells you that this is the last possible point the memory can be freed, last reference bring the first. The free needs to be between these two.
In practice, this'll li
Re: (Score:3, Informative)
Even better: Stop using C, use C++.
C++ has std::string, STL std::containers, RAII, exceptions, and a whole bunch of other stuff.
It's 2024, FFS, NOBODY should be:
* using malloc()/free()
* using strXXX()
* passing array sizes around separately from the array
* constantly rewriting boilerplate code every time they need a linked list (or whatever)
* doing stack unwinding by hand whenever an input error is detected.
* etc.
Re: (Score:2)
That's not quite enough, though. Fortunately there's also the Circle C++ [circle-lang.org] compiler that adds all of the features of Rust to C++ including a compile-time borrow checker, as new code is implemented. I think we'll see these same features added to other traditionally-insecure languages as well, with large, existing code bases. This approach has several advantages over Rust. A much lower learning curve, and it can be applied to existing projects with existing code bases as they are being developed.
I'd like to
Re: (Score:2)
Plenty of good explanations for this, however one that hasn't been given to you is that the goal of having a clear compilable Rust program which passes all of the same existing tests as a C program is a clear well defined thing that an AI system can easily be trained on. The goal of "get rid of all the bugs" is very difficult to define especially when there will be classes of bugs that you aren't aware of. In fact, some semantic "bugs" are simply choices and translating to Rust won't change them at all but
Re: (Score:2)
As I keep saying, there aren't really many pitfalls in modern C except you need to understand how to use the standard library and how to manage smart pointers. Make every raw pointer into a smart pointer of any type and you have eliminated 98% of the problems.
Re: (Score:3)
I am not quire sure what you mean by "smart pointer". C does not have smart pointers.
But generally, I agree. If you avoid open-coded string or memory buffer manipulation, have a clear ownership model for memory, and good abstractions for data structures, memory errors are not much of an issue in C, despite all the noise and Rust marketing at the moment.
Don't get me wrong, there is plenty of old C code with many issues which will keep us busy for a long time, and fixing this code would be a worthwhile goal
What about Ada? (Score:3)
I thought Ada has long been used by the DoD because of its safe handling of memory. I wonder why there is this push towards Rust when Ada is available and proven? Heck, I was dabbling in Ada back in 1990 when I was in the Marine Corps because a friend of mine that was a Grumman rep who used it recommended it to me. It has a pretty well established history and use case.
Re: (Score:3)
Re:What about Ada? (Score:4, Insightful)
You are thinking of the Pentagon 40-50 years ago. These days, they have a lot very sharp people working there and they word diligently.
Just to run an organization of that size takes a lot effort. And you must coordinate the civilian and military work forces, keep track of all the munitions, scope out new technologies, interface with all the contractors (the Pentagon doesn't build much itself, and after Reagan decided the Beltway Bandits should belly up to the trough, there are a lot of contractors), contractors of vastly different sizes and abilities.
The personnel operations are much more complicated than the largest companies, and you must answer to the nitwits in Congress and the Administration who have their own agendas.
You must also be able to navigate changes in administrations, put up with assholes who want the Navy to use steam powered catapults because they do not understand linear motors (yes, there was one Chief Asshole who wanted that).
And you must put up with Congressional dolts forcing the military to buy shit because it is made in their district and ignore whether it makes any military sense, all the while managing the spies and military threats of those nice Russian, Chinese, and Iranians, etc, etc. etc.
You must also plan for 10 and 20 and 30 and 40 years down the road because military systems and threats have shelf lives, and new systems take lot of time to field. While you are doing that planning, please be sure to think about how the systems you do have will play well together and plan for how new systems will be integrated into the existing infrastructures and that integration will be technical as well as how your forces will use it.
Before you think you can do this in an afternoon, please pay attention to the newest battlespace, space. Be sure to bring in AI as well, you'll be wanting that, and be sure you don't shoot your foot off with it.
Re: (Score:2)
I had wondered why Open Genera https://en.wikipedia.org/wiki/... [wikipedia.org] exists, why it's expensive, and why it only ran on the Alpha cpu. Turns out the government still has a need for Lisp.
Re: (Score:2)
Ada and SPARK, which is a subset that offers the actual ability to prove code works are still around, but because tools are so rare, it is cheaper for even the DoD to move to C, C++, Python, and other languages.
It would have been nice if they kept a mandate for Ada, just because it had extremely strong protection, but I'm guessing as time goes on, maybe smarter compilers can catch stupid and dangerous things, especially if AI is involved.
Maybe AI can even figure out when to just break down and do inline ass
Re: (Score:3)
Ada and SPARK, which is a subset that offers the actual ability to prove code works are still around, but because tools are so rare, it is cheaper for even the DoD to move to C, C++, Python, and other languages.
There's a SPARK compiler in GCC now.
Free as in speech and beer.
Machine analysis (Score:2)
It seems like the time is coming soon when simply adding a step like this to the commit and build steps would simply detect such issues without needing to do such a radical automated transform. What this mostly sounds like is a way to spend a bunch of tax dollars.
Re: (Score:2)
It seems like the time is coming soon when simply adding a step like this to the commit and build steps would simply detect such issues without needing to do such a radical automated transform. What this mostly sounds like is a way to spend a bunch of tax dollars.
It'll be a background task in the IDE, like the current syntax checkers.
Re: (Score:2)
I agree, it will eventually be there along with LLM powered error analysis and a lot of other power tools.
Re:Machine analysis (Score:5, Insightful)
Dude, I've been working in C and C++ for 26 years - my professional career depends on my expertise in them - in industries that take that shit very seriously (tm) and I don't know what to tell you. There's a reason why Rust is starting to eat some other lunches, and annoy people because it's now supported in lower level Linux and Windows development and is basically the kind of "change" that rustles feathers. It's real. The reasons are well publicized. It's reminds me of the resistance to helmet laws, or any other change that makes certain people upset because they feel like it upends their perception that people who make mistakes deserve going splat against the wall. Get over it. I can tell just from your "idea" that you don't actually work professionally in either of the languages. (Or if you do .. well, I fell bad for the people you do it for.)
Re: (Score:2)
I see advantages and disadvantages of all three languages. The nice thing about Rust is that it is a compiled language, and a good compiler can get as good as C for the most part. However, there are always a few things that C and C++ can do (pointer manipulation) which Rust is not as well equipped at to do.
Overall, I'm learning Rust, just because it is likely going to be what is used for low level things, where C/C++ are not explicitly needed, and I tend to prefer a low level language for a lot of things,
Re: (Score:2)
C and C++ used as fancy C (AKA C/C++) are legit hard to get right and for me at least require a significant commitment to review, test and basically being careful. If one tries to use the safer C++ idioms that are in the more modern C++ versions, and reserves the risky stuff for small and easily reasoned about sections, it's not hard to get it right.
Also concentrating on memory safety seems to me to be a bit myopic.
In summary (LOL) I think your take seems reasonable.
Re: (Score:2)
I work in C++ every day and I've only dabbled in Rust. I seldom write the sort of bugs that Rust seems designed to prevent, but I am very careful and I've been doing this a very long time. So yeah, the benefit seems pretty small to me. I do believe helmet laws and seatbelt for adults are wrong as well even though I always use both as appropriate.
A lot of people are just not careful and should do something else.
Re:Machine analysis (Score:5, Insightful)
I seldom write the sort of bugs that Rust seems designed to prevent, but I am very careful and I've been doing this a very long time.
People who truly believe this about themselves are the reason memory-safe programming environments like Rust are desperately needed in today's world.
Re: (Score:2)
So the other people can use them? :D
It's OK, C++ ain't going anywhere, carry on.
Re: (Score:2)
So without the snark, here's an example of how I didn't create one of this class of bugs. I wrote some asio based async io stuff a while back and I knew that there were some issues around cleaning up unexecuted handlers at runtime, so I looked at the source code, wrote what I thought would be a clean way to exit, and then tested it using various tools like gdb, ASAN, valgrind, and so on.
Sure enough, with the cleanup handlers it was always clean, and without it would sometimes have unfree'd blocks at exit. T
Re: (Score:2)
Comments like that prove that the people who write them are as dumb as Rust advocates are reputed to be.
It does take practice and discipline, but it's possible to do what GP claimed. I had C++ code that was much safer than the Python and Peel coffee that lived in the same stack: the Python code because it used tuples and arrays to replace structures, so you had to know what foo[3][2] meant based on the particular context and that was easy to screw up, and the Peel code was full of SQL and HTML injection po
Re:Machine analysis (Score:4, Insightful)
It does take practice and discipline, but it's possible to do what GP claimed.
Absolutely, they just have to be practiced and disciplined 100 percent of the time they're coding. Absolutely no oopsies or bad days, no glitches or slips of the keyboard are allowed. I'm sure, for example that the coder who released Heartbleed into the world is a practiced and disciplined programmer almost all of the time, ditto for the genius coder who recently broke CrowdStrike and nearly brought down Western civilisation.
That last bit was sarcasm, by the way. Half the programmers working today are less than average after all.
Re: (Score:3)
Actually I haven't used most of those tools and I probably couldn't use them perfectly 100 percent of the time if I was called on to use them. It would help if those tools didn't need to be used so much, and even when they are used they clearly don't do the job of preventing problematic code being released into the wild on a daily or even hourly basis as the constantly updated CVE lists show.
Anything that can reduce the number of civilisation-destroying oopsies making their way into production is a good thi
Re: (Score:2)
Re: (Score:2)
Dude,
"change" that rustles feathers.
It's real
Get over it.
Why such attitude? Seems rather common with the folks pushing Rust.
It wouldn't work. (Score:5, Interesting)
It wouldn't work beyond simple examples. Semantically C and Rust are quite different, so the AI will always have to make guesses about what the C is *really* trying to do when it does something like *((arr + i * M) + j2) and try to reimplement it properly in Rust since Rust doesn't have pointer arithmetic and encoding self referential data structures are hard in Rust due to lifetimes and borrow checking. It would be much more successful to use AI to disallow pointers and convert such C code into C++ with smart pointers and liberal use of std::optional . In such a conversion, much of the code could remain nearly the same and there is a direct translation for most common c options.
Re: (Score:3)
Not forgetting... Rust has no preprocessor support...
The pointer stuff and the fact that C can, indeed often does, include raw assembly .... this could be interesting.
Would love to see the first outputs so I could grab the snapshot and frame it.
Re: It wouldn't work. (Score:3)
You mean inline assembly?
https://doc.rust-lang.org/refe... [rust-lang.org]
Re: (Score:3)
You mean inline assembly?
Rust's approach to inline assembly is significantly different to that of C.... from the AI point of view, this is a non-trivial context switch.
Re: (Score:2)
How so?
Re: (Score:2)
How so?
How not so?
Rust's assertion to memory-safety *requires* additional controls around inline assembly, with a bunch of new requirements around its use.
C/C++ provide none of that. This will require context switch to assess the assembly, determine its function, then rejig it to comply.
Point being, claiming it's straight C-to-Rust translation is false. There's a lot more to it.
Re: It wouldn't work. (Score:2)
Those are rules the programmer to follow to avoid undefined behavior. It's a black box to the compiler.
Re: (Score:2)
Those are rules the programmer to follow to avoid undefined behavior.
In context of TFA, there is no programmer....
Good enough for government work ... (Score:2)
It wouldn't work beyond simple examples.
But that is good enough for Master's and PhD Thesis, and research grants, and academic publications.
Some of the earliest advice from my Thesis Advisor was to stay away from real world complexity. Such complexity is not necessary for a research project. Research can use somewhat simplified inputs, sample cases, to solve conceptual problems. For example a computer vision problem based on synthetic images rather than real world images. Telling an ambulance from a tank was a very well funded area of research
Re: (Score:2)
Ah yes, the classic solution for spherical cows of unit size and uniform density. :D
Re: (Score:2)
what the C is *really* trying to do when it does something like *((arr + i * M) + j2)
The number of C programmers who can write or understand that kind of code is vanishingly small these days.
I worked on Automatically Transpiled C... (Score:5, Interesting)
The BIOC worked properly (after being built by the BIOC-builder), but Honeywell was spending something like 200k / year with Sun on a lease for a Sun microcomputer to compile this ONE application. The software team would often times modify the BIOC after it was built, since it was basically impossible for anyone to change the BIOC-builder. This was expensive, time consuming, and sucked big time for applying this ever-increasing sequences of patches.
Sounds like a good project for a summer intern, right?
The nice thing about the Sun compiler Honeywell used was that it zero padded all arrays Like, every single memory allocation routine would return you a bunch of zero'd out memory, even if you specifically did not ask for that. The PC compiler took a much more literal, and less wasteful, approach of only giving you zero'd memory when you'd ask for it. The machine-generated code never asked for memory to be allocated with zeros, which meant every single string copy, memory copy, or pretty much everything that operated over an array died. So I had to rewrite all memory allocation. After I did this, and got to be really good with Valgrind, I changed TWO lines of code that had to do with byte order indexing differences between the Sun and PC, generated the BIOC-builder, generated a BIOC, passed all avionics related tests, had a bunch of high fives and left early to drink a beer, or seven, to celebrate. We got the rest of the team set up later that week, or the week after.
This would have been better in Rust. This would have been even better if the corporate overlords, and all the engineers involved, pushed to understand something they heavily depended on. Yes, they had work-arounds. Yes, those work-arounds sucked big time.
Machine generating code lends itself to a lack of understanding. Sometimes that's desirable, such as the fact that I REALLY don't understand any kind of assembly very well, but can (could?) write C and C++ all right. Sometimes that's not, like when you're paying Sun 200k / year in 2005 dollars for a machine to maintain super critical code that no one understands, and no one can work on.
Honeywell offered me a job. I hate cubicles though, so I turned it down. I was like 22, and if I'd been thinking properly at that time, I'd have countered with an offer to be a contractor.
Re: (Score:2)
Does replacing malloc with calloc (even if you do that with a macro of some kind) really take that long?
I remember once just #defining malloc to be calloc to diagnose a problem (that just wasn't worth firing up a debugger for, especially as it then immediately revealed the problem because the program stopped crashing at a given line, meaning I knew it was just an missing initialiser somewhere related to that line).
Re: (Score:3)
The BIOC-builder was built using C code. However, this C code was not written by a rational human being, an irrational human being, or any kind of human being at all, but a compilation process from some other language no one had access to, could remember, or do anything with.
Reminds me of dBase III. dBase & dBase were written in hand-crafted assembly, but it was getting difficult to maintain and almost impossible to port. So Ashton-Tate wrote an x86 ASM to C converter and converted the millions of lines of asm to C. The resulting code, whilst able to compile, was reportedly inhuman in syntax and virtually unreadable. It also wan;' very good, if you're of an age that can remember the firestorm surrounding dBase III's release.
Re: (Score:2)
Machine generating code lends itself to a lack of understanding
I looked at a lot of machine translation projects in the '9s. This one line sums it all up very nicely! The resulting code was not comprehensible, and the "why" that might have come from comments was completely lost. The net result on a large project was that you'd spend -more- on maintenance than you would have to train a couple of programmers in the "old fashioned no one uses this" original language.
A pretty difficult proposition (Score:5, Interesting)
As I started writing my comment I was thinking it would be impossible, but I suspect that 80% of C code is "safe", in the sense that it's not doing pointer arithmetic, isn't writing to buffers, isn't multi-threaded and isn't malloc/free'ing stuff. So maybe that code could be transpiled. I don't think the transpiled code would look pretty, but if the code is "safe" (implicitly, not explicitly) then it should map over.
The biggest issue I see is it would write Rust like a C programmer would. For example, a Rust programmer would iterate a collection using functional programming, where a C programmer would do it by index. This would extend to things like move semantics, boxes (smart pointers) for memory allocation, using Send traits for thread safety, atomic reference counting, function interfaces, borrows, strings, collections and so on. Meanwhile C code is going to have macros, lots of unsafe pointer stuff going on, lots of helper functions for things like strings, collections etc. which may or may not be correct.
On top of that C code is typically going to expose methods which are inherently unsafe, e.g. if I have foolib, then it might have methods foo_init(ptr), foo_shutdown(ptr), foo_alloc_xxxx(), foo_free_xxxx(ptr), foo_copy_xxxx(ptr) and so on. Anything ptr here is a struct of some kind which the client is supposed to call properly and while Rust supports pointers, it mostly treats them as unsafe. So if the APIs the same, they are marked unsafe and there would be unsafe chunks all over the place. Obviously if a transpiled client is calling a transpiled library then it's kind of stupid they are shoehorned through an unsafe API for no reason. I would see the optimal solution is unsafe "legacy" APIs for existing C clients and new safe RAII style bindings for Rust clients.
So it will be interesting to see what the project does to tackle the issues that to me are - a) correctness, b) maintainability, c) minimal unsafe blocks, d) Rust semantics. I have no doubt to me having used Rust extensively (and I still use C/C++ elsewhere) that it is a vast improvement over C and C++ in terms of safety and stability so it would be fantastic to see some libraries use it.
Re: (Score:2)
I'd be interested to know what kind of dross people are writing that doesn't allocate dynamic memory in a C program or require a second thread.
To be honest, if that forms even 1% of the codebase, it should just be thrown away and forgotten about because you can probably replace it with an Excel macro.
Hire real programmers to do it extend (Score:2)
Stop fetishizing C (Score:4, Insightful)
There seems to be a macho culture around C programming, and a lot of people feel very threatened anytime it's pointed out that memory unsafety is costing the world billions of dollars a year in breaks and security issues.
We don't need memory unsafe languages anymore, at least not outside niche domains like embedded computing. Their replacement with Rust can only be a good thing.
Re: (Score:3)
I'd hardly call embedded computing niche. Just look around you.
Re: (Score:3)
We don't need memory unsafe languages anymore
Who is this "we" that you are talking about? How about, "You do not need memory unsafe languages and you are not aware of anyone who does"?
Your type of unsafe thinking is why memory unsafe languages have issues.
Of course (Score:3)
"Memory safety bugs, such buffer overflows, account for the majority of major vulnerabilities in large codebases. "
That's why Wordpress basically has no vulnerabilities.
Re: (Score:2)
And by implication, fixing 51% of "major vulnerabilities" is Good Enough For Government Work.
Rust Jokes (Score:2)
- Only AI write Rust code, and even then it hallucinate C/C++, only.
- The problem with memory safety best practices is that nobody remember them, but it seems it's not the case with a rusty memory, go figure.
- Having the White House promoting Rust is like having your mother at the classroom telling your classmates that you are really cool: "Please, be friend of my son!"
- Having DARPA promoting Rust is like having your bigger brother bullying your classmates to give him their lunch money; and he will not eve
Rust is the new Ada (Score:2)
Rust is Ada with programming socks
C is bad, but not necessarily C++ (Score:2)
Just make sure it uses safe code (Score:2)
The AI better be fed with reviewed safe code.
I'm not familiar with Rust but know a little C, and just asked ChatCPT 3.5 (through DuckduckGo Chat) to create a vector implementation. The first thing I noticed it did no pointer check after malloc().
I had to explicitly request "safe C code" for it to return code with error and boundary checking.
It should have returned the second version by default but I guess so many write code without verifying input and output that the AI assumes unsafe code is the desired an
Makes Sense (Score:3, Funny)
Nothing useful was actually finished while being written in Rust, not even Servo. [wikipedia.org]
What does it mean? That it's a perfect candidate for governmental projects.
The creator of Rust thought of calling it B, for Bureaucratic, but since B was taken then Rust filled the place, I mean what is the difference between something rusted and something bureaucratic?
Bad Headline (Score:3)
A more accurate headline would be something like "DARPA wants to replace all C memory safety vulns with AI-transpilation-to-Rust errors."
There will probably also be second order problems with maintenance of the auto-generated code.
Clueless. (Score:3)
prediction: The resultant code will be full of errors and completely unsupportable, not least because the actual intent behind the code will be lost in translation, and replaced with a bunch of "seems to do the same thing" code.
Re: (Score:3, Insightful)
COBOL is intended for business logic, which typically doesn't demand high performance and isn't bothered by being far removed from the metal. Javascript is usable for the former, but is completely unsuitable for the latter.
Re: (Score:3)
COBOL is good for money because you can do math in BCD. Javascript is going to use floats. You do not want to process money using floats.
Technically they're doubles. A double can represent all the integers from 0 to 2^52 with perfect accuracy.
You won't need them though, Javascript has BigInt [mozilla.org].
Re: (Score:2)
Javascript has BigInt numbers too.
Re: (Score:2)
Major banks intend to use A.I. to translate their legacy COBOL code base - something that can only be maintained by increasingly rare and expensive COBOL contractors - into Javascript - something that can be maintained by free and ever-plentiful interns.
You mean labor located in countries where the cost of living is next to nothing? Or do you mean teenagers?
Re: (Score:2)
What can possibly go wrong?
java for gpu's? (Score:2)
java for gpu's?
Re: (Score:2)
Ultimately reverse compile any binary into any language and then retarget it to a new CPU architecture or GPU. I get ahead of myself though.
Java was the next big thing 25 years ago. The next big thing changes all the time. If we transpiled all old code bases into the next big thing, then we'd lose the history that has gone into our code bases. Would be handy though to be able to convert a code base in one language to another language easily. Take all your Python code and compile it to something performant,
Re: (Score:2)
Wishful thinking though. Even Java and C# are not easy to translate to one another even though they were born almost alike. For example, Java still doesn't have async/await, so how do you transpile a C# async/await code? Sure, you can generate your state machine but then the generated Java is an unreadable and unmaintainable blurb of generated code.
All syntactic sugar and idiosyncrasies of all languages make them unique. I'm sure you can transpile then into one another, but the result would be the language
Re: (Score:2)
I know, it just doesn't work does it. But this is AI conversion. AI should be derive the intent of a large code base, and then recreate that intent using all the idioms of the target language.
Re: (Score:2)
You're right, it should.
My definition of technical debt is any piece of code that a human hasn't meddled with on a regular basis. This is code that people need to ramp up on before doing any change to it, it takes much more time.
With AI translation, you instantly come up with a pile of tech debt since no human has ever touched it before. Why did the AI make that choice? Will there be a side effect if I do this? Will the AI that generated the code be able to answer those questions?
If not, it sounds like a b
Re: (Score:2)
Re: (Score:2)
billions of devices can now run Java
The goal.
none of them do it very well?
Not the goal.
Re: (Score:3)
IDE will run AI while waiting for you to type (Score:2)
Because developers can add code after the fact that introduce more problems with memory safety.
And you run the AI again. Face it, the AI bug checker will become a background task in the IDE, like our current syntax checkers. It'll happen automatically while the IDE is sitting there waiting for you to type.
Re: (Score:2)
Well stop adding code then. At some point your software works as designed and is bug free. You're at the peak. From here it can only go downhill.
Re: (Score:2)
And in addition to what the sibling AC posted, for now morons can't write Rust, particularly if you restrict them from putting "unsafe" everywhere. I've had problems I could barely solve in Rust, so the bar of being able to code in it is way above "moron". In my humble opinion.
Re: People Still Don't Get (Score:3)
If you're trying to learn rust for the first time, using unsafe is very unlikely to help you get your code to compile, especially if you're struggling with the borrow checker.
Re: (Score:2)
Really? You can certainly use unsafe code to stick your data in the global scope. I seem to recall you can also use unsafe code to make something mutable that shouldn't be.
The unsafe keyword won't make your code compile, but it may let you do something ugly to bypass the problem.
Re: (Score:2)
Here we have someone commenting on Rust that's never actually used Rust. Ever tried using "unsafe" in a real program? If you had you'd know that it's not some mighty hammer that trumps all the rules. It doesn't work like that. There are still rules, and the compiler enforces them. Neophyte Rust programmers don't know the rules, and when they start "unsafe"-ing things they get tangled up very fast.
Unsafe allows you to break certain specific rules and then taints the containing code.
Re: (Score:2)
Here we have someone commenting on Rust that's never actually used Rust.
Alright, we're jumping right to assuming bad faith aren't we...
Re: (Score:2)
Re: (Score:2)
... you have to have the synchros replaced every few thousand miles, they grind loudly when shifting gears, and your 1-5 gears start sprouting neutrals ...
Wow my old F-350 has none of those problems at close to 200K miles but perhaps it depends on how it's operated. Not completely unlike coding I suppose.
Re: (Score:2)
And that is the question. As you say, none of the things that the OP says are actually true about manual transmission. There again, the complexity of using a manual gearbox is not high and they have distinct advantages over automatic which is why most cars in many parts of the world are manual.
If Rust is an automatic, is C a modern manual car, or a pre-syncho manual with double declutching and all that entails?
How about that for stretching a metaphor past the point on insanity?
Re: (Score:2)
How about that for stretching a metaphor past the point on insanity?
So taking it even further .... :D
In my experience automatic transmissions actually require more more maintenance more frequently than a good old manual stick if care is taken and the driver knows how to drive properly. I honestly don't see how THAT would apply to C++ vs Rust but it was fun.
Re: (Score:2)
In my experience most of neither need any maintenance if you do timely fluid changes, the intervals for which should be much shorter than suggested by the manufacturer in almost every case. And especially the first change in an automatic should come MUCH sooner than suggested.
Some pickups also badly need additional transmission cooling because their transmissions are based on older models, which were insufficiently updated when making cost-reducing changes. For example the E4OD is based on the C6, but the C
Re: (Score:3)
Anywhere, in normal professional usage, that you're doing the kind of memory manipulation that Rust insists has to be done inside an unsafe block... is risky in any language. Including Rust. Because that's literally why it's called unsafe. And unsafe mode CAN INTERFERE WITH THE GUARANTEES of the rest of the supposedly "safe" code that's not marked with it.
And there are a ton of things that you literally have to perform "unsafe" actions to do... anything that involves direct hardware access (every driver,
Re: (Score:2)
Re: (Score:2)
No, I don't think you can. The semantics of the language have a direct impact on the static logic that you can apply. Is this statement in python valid or invalid and what is the type of `x`?
x = eval(f"{x} + {y}")
Re: (Score:2)