I’m not a fan of “being cute” in papers typically, for the reason that it detracts from the central ideas. Clearly this happened here.

These discussions frequently feel “tense”, wherein criticisms based on specific technical details are tied to an attack on the language as a whole.

In that context, the authors definitely shot themselves in the foot with the opening/title.

it seems under this view, the conclusion that can be drawn for the paper is “replacing parts of a C codebase with the conceptually equivalent Rust code without any thought as to the nuances of Rust ffi may lead to bugs if the C code is already contrived” which doesn’t seem too useful a conclusion to me.

The conclusion is

“you have to think hard to avoid UB via rust’s FFI mechanics.”

this is contrary to rust’s aims to make such bugs impossible, rather than just hard.

Hence their proposal for a DSL _in rust_, which makes those bugs impossible.

The authors are providing a solution to a clearly identified problem, with the goal of making rust better.

Despite the poor intro, the ideas in the paper are “let’s shrink the unsafe boundary”, not “let’s stick to writing what we know(C).”