"we model a scenario where the original code is memory-safe; the ported code is memory-safe; and we consider memory safety and undefined behavior that may arise across the FFI layer between the two pieces of code."<p>I may be stating the obvious, but that's a bit of a strawman. Yes, writing good FFI code is hard; yes it could result in security/soundness issues; yes, we could use better tools in this space.<p>But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards, even accounting for the potential problems at the FFI boundary.<p>If I could remove tens of thousands of lines of hard-to-analyze C code, and replace it with tens of thousands of lines of safe Rust, paired with a few hundred lines of hard-to-analyze FFI adapters, that sounds like a pretty good tradeoff to me. I now know exactly where to focus my attention, and I can have confidence that the situation will only improve with time: better tooling may allow me to improve the dangerous FFI layer, and in the meantime I can recklessly improve the safe Rust module without fear of introducing new memory unsafety bugs, unsound behavior, or data races.
As a hobbyist with only limited C++ and Rust experience, reading things like the abstract of this paper push me towards Rust a bit.<p>The snark is really offputting. As a user of software trying to protect my personal information in an increasingly threatening world, I would like memory safety in more places. From the outside looking in it feels like there are a lot of C and C++ programmers trying to deflect from how poorly their attempts at memory safety have gone and just snarking at the people trying to fix it.<p>I will say that the point about FFI boundaries needing more care is a valid one I had not considered.<p>Is there a name for people who don't work in C++ and never, ever hear "rewrite it in Rust" except from programmers who seem like they're a bit hurt that their language has a competitor?
Ah yes, the "* Considered Harmful" tradition in computer science. A tradition so widespread that it has even wrapped around upon itself and yielded the "'Considered harmful' considered harmful" paper.<p>Not the best start already. Hmm, written by 'Anonymous Authors'. So is this supposed to be a joke? Is the implication that speaking out against rust makes you the target of unjust persecution? Is it written by people known to have an axe to grind?<p>Abstract: This is a free-verse poem setting up a rust advocate strawman. Do such people exist on the internet? Yes. But time cube also exists on the internet.<p>Introduction: Incrementally rewriting a C/C++ system in rust is bad because FFI can have problems. Which can be simplified with a different spin to be, "C/C++ are so bad that they contaminate even the mighty rust."<p>It feels like the paper might have some good information that would be useful to people who want to augment their codebases with rust. However, it starts off so combative, that I don't think I could seriously recommend anyone actually read it. Maybe just skip the abstract and intro and see what you get out of it?
There's a certain tendency to take anything written in a double column PDF followed by a long list of citations as gospel. Maybe that's what the authors were hoping for? The poor quality of writing, contrived examples and unnecessary snark could be why the authors didn't to put their name to this paper.
I'm possibly misunderstanding, but their first example doesn't make sense to me:<p>1. C can make aggressive aliasing optimizations based on observable behavior, meaning that the compiler <i>may</i> or <i>may not</i> optimize `add_twice` based on the results of any alias analysis it chooses to do. In other words: the author's assumption that a C compiler <i>won't</i> optimize `add_twice` in the same way that Rust will is not a guarantee, and assuming that it won't is relying on unspecified behavior.<p>2. The author claims that the result of the optimization can result in memory unsafety, and it's not immediately clear to me that that's true: it might be true in an <i>interprocedural</i> sense due to another function's assumptions about how `add_twice` affects its parameters, but this is the same incorrect assumption as in (1). In that sense, Rust is not really involved at all here.
I think some folks are misreading the authors intentions(possibly due to aforementioned snark): they’re not advocating for sticking to existing C codebases over rust.<p>They identify FFI as an area where it is easy to make mistakes which lead to undefined behavior, argue that it is the result of competing assumptions between C and rust, and then propose a formal system implemented in both in C and in Rust to resolve those issues.<p>Sure, the problems they identify wouldn’t exist if everything was rewritten in Rust, but on a large enough / old enough codebase, that may impossible to do all at once. This paper attempts to find a way to make rust better within those organizational constraints.<p>The audience here is not engineering managers deciding in your next tech stack, but programming language researchers.
> Anonymous Authors<p>Because no-one would want to put their name to this.<p>There may be some valid arguments in there (though it seems to be just "FFI is hard ergo noone should never attempt phased migration of any system codebase"), but even content aside, the tone is that of a moody teenager. The abstract in particular is one of the worst things I've ever read - the introduction doesn't read fantastically eitherr.
The authors don't seem to understand memory safety or FFI and wrote a contrived article about it.<p>Hell, the first example isn't equivalent code. You can't share references across an FFI boundary with C.
This is not literally from 2017. It’s a preprint; the 2017 bit in the footer is from the default article template. Per the footer, it’s actually from 2023. You can tell because the abstract mentions SBF and Madoff in the same sentence!
There's plenty of good content in this paper. FFI safety is a very important topic, and there are unique concerns with Rust FFI. Such a shame it devolves into unprofessional and inflammatory remarks. The authors could have put their names on the paper and gotten a decent credit if they could have kept their emotional responses to the topic out of it.
"Rewrite it in ____" should pretty much always be a last restort. Rewriting takes a ton of time and effort, has its own downsides, and just generally doesn't have as obvious a value add to customers/consumers (outside of pretty specific scenarios) to justify the cost. Plus, rewriting anything in anything else just invites a whole new suite of problems with the new thing that probably/definitely weren't accounted for.<p>Now, for personal software I say hell yes. If a person is writing code for the fun of it, or simply wants to learn about concepts, rewrite whatever in whatever and have a great time. That's the point! But for professional/commercial software, rewriting is probably more expensive than is realized.
The title and subtitle seem completely unrelated. I'm not advocating for rewriting everything but seems like most rewrites won't be using FFI
Wow, this is extremely relevant to my current work (porting from Go to Rust). Adding on to the paper, some other issues are:<p>- Modeling concurrency across boundaries, like if you're p using goroutines but also tokio, how the heck does that work?<p>- Persisting data across FFI, like if you have some Go code that calls Rust, and you want the Rust code to persist stuff in memory, that gets tricky fast.<p>- Assumptions around strings. Go will give you a bag o' bytes and say "it's a string, trust me!" while Rust expects UTF-8.<p>We definitely ran into some of these issues, like remembering who should deallocate which memory.
Although the paper's title and abstract seem to be intentionally trying to stir controversy and annoy people, the core issue of FFI unsafety is real.<p>C has many subtle behaviors, and a type system that doesn't describe them well. It also can't express its API's ownership or thread-safety, and there's no true immutability. Correctness of the ABI isn't enforced in any way, so you just smush symbols together and hope for the best. That is ripe for errors, especially when you try to add extra guarantees on the Rust side that C may or may not actually provide.
now here we have "X considered harmful" - a common Trope.
This seems more like a "First!" to title their paper this, as a meme of the whitepaper meta, that title came first, then the arguments came.
I say this because I joked about a paper being released with this name about a week ago and now here it is, but Its a bit lower quality than expected.
We might need another one later...
A lot of the commenters don't seem to understand the thrust of this paper. First, the use of "considered harmful" here is tongue-in-cheek or at least self-aware. Second, the point of the paper is not to say that rewriting in Rust is bad, but to propose a safer approach to incremental rewrites that addresses (what the authors argue is) the risk of introducing new bugs at the C/Rust boundary.
I really don’t understand the people who have a problem with rust. Do you not value the increased memory safety? Now that Microsoft and Google are adopting rust and reporting significant decreases in memory related bugs it’s pretty clear that rust does make a difference.