Surely this could be better pitched to researchers as just another AI benchmark, a bit like ARC Prize? ;)
There could be some exiting C projects that are already public, with tests for feedback during development iteration and some holdout tests, and some holdout projects too with a leaderboard and prizes.
For preferences about converted code quality, both automated assesment and human preferences could be ranked with Elo? Kaggle is made for this sort of thing I think?
I'm sure Google Deepmind and others have some MCTS agents that could do a great job with a bit of effort.
Translating All C to Rust (TRACTOR)
191–200 of 403 posts
Re: Translating All C to Rust (TRACTOR)
#192Earlier quoted context omitted.
> They are not UB-as-a-feature like in C/C++. That's the part that's incorrect. That, plus the implication that UB is a bug in Rust, but not in C++. As I said, the existence of UB is a feature in both languages and actually encountering UB is a bug in both languages. You can play with the semantics of the word "feature" but I don't think it's possible to find a definition that captures C++ UB and excludes Rust UB wit…
You’re done editing the comment now? Do you think UB-as-feature is something that someone would honestly describe C or C++ as? It’s a pretty demeaning way of framing things. Indeed it’s a tongue-in-cheek remark, a vhimsical exaggeration/description of the by-default UB of those languages which was added to the end of the completely factual description of the role that finding UB in the Safe Rust subset of the standar…
> Do you think UB-as-feature is something that someone would honestly describe C or C++ as?
Yes. That's how I describe it. That's also how Ralf Jung (long time Rust contributor and one of the main people behind Miri) describes UB in both Rust and C++ (although he says C++ overdoes it) [1]
The thing I edited out of my comment was "motte and bailey fallacy" because after reflecting a bit I thought it was unfair. But now you're actually trying to retroactively reframe as a joke.
[1] https://blog.sigplan.org/2021/11/18/undefined-behavior-deser...
Re: Translating All C to Rust (TRACTOR)
#193Earlier quoted context omitted.
> have to imagine that in the general case it will be a translation to unsafe Rust, with occasional isolated leaf nodes being translated to safe Rust. That’s not what they are aiming for. FTA: “The goal is to achieve the same quality and style that a skilled Rust developer would produce” > just imagine how much harder it is to write automatic translation to borrow-checker-approved code that accounts for all the possi…
> undefined behavior gives the compiler leeway in deciding what a program does, so the more undefined behavior a C program invokes, the easier it is to translate its code to rust. You assume that the compiler can determine what behavior is undefined. It can't. C compilers don't just look at some individual line of the program and say "oh, that's undefined, unleash the nasal demons". C compilers look at code, reason t…
I (not the person you are replying to) do understand that's how compilers interact with UB. However, a wealth of experience has shown us that the assumption "UB doesn't occur" is completely false. It is, in my opinion, quite irresponsible for compiler writers to continue to use a known-false assumption when building the optimizer. I don't really care how much speed it costs, we need to stop building software on a shaky foundation like that.
Re: Translating All C to Rust (TRACTOR)
#194This isn't some "pie in the sky" thing, Immunant has a working C to Rust transpiler and it's really interesting: https://github.com/immunant/c2rust
I've tried that thing. The Rust that comes out is terrible. It converts C into a set of Rust function calls which explicitly emulate C semantics by manipulating raw pointers. It doesn't even convert C arrays to a Vec. It's a brute-force transliteration, not a translation. I and someone else ran this on a JPEG 2000 decoder that sometimes crashed with a bad memory reference. The Rust version crashed with the same bad m…
> I ran this on a JPEG 2000 decoder that sometimes crashed with a bad memory reference. The Rust version crashed with the same bad memory reference. It's bug-compatible.
Of course it is. The README says it generates unsafe rust in the first paragraph, what did you expect?
I think it's a really fascinating experiment, and IMHO it's pretty remarkable what it can do. This is an incredibly difficult problem after all...
Re: Translating All C to Rust (TRACTOR)
#195Every tool has its own specific quirks. Over many years of using a tool, "expertise" is the intimate knowledge of those quirks and how to use that tool most effectively. Changing tools requires you to gain expertise again. You're going to be less proficient in the new tool for a long time, and make a lot of mistakes. Considering we already know how to make C/C++ programs memory safe, it's bizarre that people would di…
> Considering we already know how to make C/C++ programs memory safe...
I think that the legion of memory bugs which still occur in C/C++ programs are proof of one of two things:
1. We (the industry as a whole) do not actually know how to make these programs memory safe, or
2. Knowing how to make programs memory safe in C/C++ is not sufficient to prevent memory safety issues.
Either way, it seems clear that something needs to be done and that the status quo in C/C++ programming is not enough. I'm not saying Rust will be the right answer in the end (I do like it, but there's a ton of hype and hype makes me distrustful), but I can't fault people for wanting to try something new.
Re: Translating All C to Rust (TRACTOR)
#196Technically, Zig has this functionality built in via translate-c, but it's designed for reading by a C compiler, not a human
Well, the main idea is memory-safety. Zig is certainly better, but not as memory-safe.
PS: Java or even JavaScript are memory-safe :)
Re: Translating All C to Rust (TRACTOR)
#197Earlier quoted context omitted.
> undefined behavior gives the compiler leeway in deciding what a program does, so the more undefined behavior a C program invokes, the easier it is to translate its code to rust. That's the kind of language lawyer approach that caused a rebellion in the last decade amongst C programmers against irresponsible compiler optimizations. "Who cares if your program actually works as intended? My optimization is legal accor…
> Who cares if your program actually works as intended? My optimization is legal according to the standard, it's your program that's relying written to exploit loopholes". If your program invokes undefined behaviour, it's invalid and non-portable. Out of bounds array accesses are UB, yet a program containing them may just happen to work. It won't be portable even between different compiler versions. The C standard is…
If undefined behavior is invalid, then reject the program instead of "optimizing" it. This "oh look undefined behavior I'm gonna turn the entire function into a no-op" nonsense is completely unacceptable. It's adversarial and borders on malicious. Null pointer check deletion can turn bugs into exploitable vulnerabilities.
Re: Translating All C to Rust (TRACTOR)
#198Earlier quoted context omitted.
If you have dormant code, as in running everywhere but not getting worked on anywhere, a "translate to shitty rust before ever touching again" has a certain appeal. Not the appeal of an obviously good idea: chances are the "shitty rust" created through translation would be so much worse to work on than C with some level of background noise of bugs (that would also be present in the "shitty rust" thanks to faithful tr…
In my experience (supporting a machine-translated codebase which resulted in shitty Java) your theory doesn't play out. If you give developers a shitty codebase then those developers will leave to work somewhere else. After a few years of working on this codebase we had 88% turnover. 1 in 10 developers remembered the original project's design philosophy and intention. It wasn't a good situation.
GP was proposing a different situation where the source code is not changing or changing very rarely. If you have a high churn codebase, obviously the maintenance experience will worsen dramatically after machine translation (at least with many current tools), so your experience is not unexpected.
Re: Translating All C to Rust (TRACTOR)
#199Earlier quoted context omitted.
I am fully in the RIIR koolaid, but SQLite would be near the absolute bottom of my prioritization list. Care to explain? SQLite is extensively tested, has requirements to run on ~every platform, be backwards compatible, and has a relatively small blast radius if there is a C derived bug. There is much more fertile ground in any number of core system services (network, sudo, dns, etc)
Not a small blast radius. There are an estimated 1 trillion active deployed SQLite instances: https://news.ycombinator.com/item?id=29461127
Fair. But perhaps it has a narrow attack surface.
Re: Translating All C to Rust (TRACTOR)
#200I'm personally not a fan of "rewrite the world in Rust" mentality, but that being said, if one is planning to port a project to a new language or platform, mechanical translation is a poor means of doing so. Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece. Don't build a castle in the sky, because it will never reach the ground. If you've…
> I'm personally not a fan of "rewrite the world in Rust" mentality There is no such mentality anywhere. There is a ton of software that's much better off left alone in a dynamic language, or a statically typed language with a garbage collector (like Golang). Good engineers understand the idea of using the right tool for the job. The push is to start reducing those memory safety CVEs because they have been proven to…
> There is no such mentality anywhere.
There definitely is. Mainstream and official Rust community material is generally sane, but the meme did not come from nowhere. The rewrite-everything people are out there.