Live data from Hacker News

Translating All C to Rust (TRACTOR)

darpa.mil

371–380 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#371

I program in C++ and am very happy to do so. Modern C++ is very safe and actually fun to program in. It gives me enormous expressivity, extraordinary performance and safety when I need it. I'm not building space shuttles, I'm building 3D experiences, so I'm not terribly concerned about crashes. But even for me, I've not run into a memory corruption bug in recent memory (10-15 years.) Bash C/C++ all you want. I'm happ…

I program in modern C++ as well (C++23). I disagree with both "very safe" and "fun". Even with 23 there are an innumerable number of footguns throughout both the language and the standard library. Debugging code is also a mess. Good luck getting anything done without paying for an IDE, and even then it can be a struggle.

Re: Translating All C to Rust (TRACTOR)

#372
post #365

If we have smart AIs to write code, find bugs, and write tests - doesn’t that mean we can ditch the “safe” languages and go back to C? Thats mostly a joke. But AI-hardened-C seems like it could be much better than current-human-only-C.

It’s not any more of a joke than the hee-haw nonsense that using an LLM to translate working C code into something else will yield a result with fewer bugs.

Re: Translating All C to Rust (TRACTOR)

#373

I program in C++ and am very happy to do so. Modern C++ is very safe and actually fun to program in. It gives me enormous expressivity, extraordinary performance and safety when I need it. I'm not building space shuttles, I'm building 3D experiences, so I'm not terribly concerned about crashes. But even for me, I've not run into a memory corruption bug in recent memory (10-15 years.) Bash C/C++ all you want. I'm happ…

I program in modern C++ as well (C++23). I disagree with both "very safe" and "fun". Even with 23 there are an innumerable number of footguns throughout both the language and the standard library. Debugging code is also a mess. Good luck getting anything done without paying for an IDE, and even then it can be a struggle.

Of all the languages I use C/C++ have the least need for paid tools.

I use emacs(and vim), make and Boost's b2 build system for most of my programming. Although on Windows, Visual Studio is a joy to use. On Linux I use gdb. Works fine. I also use static analysers and valgrind. But I come from a tradition of Unix and living on the command line.

I've tried CLion, because I pay for IntelliJ IDEA for other programming (I also have to write Javascript, and Python) But while its nice, there is nothing there that I couldn't do without.

If you stick to C++ standard libraries, Boost, and turn on all warnings, and are reasonably competent, you won't encounter any bugs that are so serious that your program crashes inexplicably.

Re: Translating All C to Rust (TRACTOR)

#376
post #364

> Those involved with the oversight of C and C++ have pushed back, arguing that proper adherence to ISO standards and diligent application of testing tools can achieve comparable results without reinventing everything in Rust. If you stick to extremely stringent coding practices and incorporate third party static verification tools that require riddling your code with proprietary situations, then sure, you can achiev…

It's quite hilarious to see the push back rust gets by the c/c++ community. Obviously their decades of hard work and experience to work with those languages are overriding their reasoning circuits. Who in their right mind would defend a language that has such major and obvious design flaws if a genuine alternative is there.

Many of the most widely used languages have obvious major design flaws. (JavaScript is one obvious candidate, python is another. How did a language which has no built-in floating point type become the number one language for numerical analysis?)

The real question is what tradeoffs you are making and what you are gaining. Rust makes certain memory safety guarantees about the program at compile time, but at the same time it disallows perfectly safe constructions, which can exist in C++, as well.

Re: Translating All C to Rust (TRACTOR)

#377

My experience of AI as a coding assistant: for Python - awesome for golang - awesome for JavaScript - awesome for Zig - not awesome, AI doesn't get it, maybe training data set too small for Rust - terrible - AI really doesn't get how it works, especially the hard bits

If you can cobble your program together by copy/pasting Stack Overflow snippets, an AI tends to be useful.

Your list reflects that.

Re: Translating All C to Rust (TRACTOR)

#378

If you translate the code from C to Rust automatically. Isn't C still the source code? Just transpiled to Rust as an intermediate before asm?

Indeed. Think of the AI stage as “llmcc”, or maybe “lsdcc” if you want to emphasize the hallucination problem.

Re: Translating All C to Rust (TRACTOR)

#379
I don't see this working. There are abstractions in C which are not replicable in Rust, without major changes.

In C, having two separate data structures which carry an identical pointer and are writing to it is a common occurrence. This can not be trivially replicated in rust and will need some reasonably clever intervention.

Re: Translating All C to Rust (TRACTOR)

#380
post #364

Earlier quoted context omitted.

It's quite hilarious to see the push back rust gets by the c/c++ community. Obviously their decades of hard work and experience to work with those languages are overriding their reasoning circuits. Who in their right mind would defend a language that has such major and obvious design flaws if a genuine alternative is there.

Many of the most widely used languages have obvious major design flaws. (JavaScript is one obvious candidate, python is another. How did a language which has no built-in floating point type become the number one language for numerical analysis?) The real question is what tradeoffs you are making and what you are gaining. Rust makes certain memory safety guarantees about the program at compile time, but at the same ti…

I think DARPA is making the right decision about choosing Rust as the language for low level systems programming. For national security related matters you'd definitely want the certainty Rust brings.

The reason I personally chose Rust as my go to language for low level programming is that despite learning systems programming in college I pretty much never used it outside of school. Meaning I didn't have any of that knowledge that c and c++ programmers had built up over years of experience. So I decided that instead of having to deal with the unknown skill deficiencies in writing concurrent software and memory management I'd rather just have a compiler scream at me. I don't regret the decision.

Also, I remember writing an async TCP implementation in college with c++ using boost. Rust tooling is just so far ahead of that.

Post reply on HN