5 ms·

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

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. 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. 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. The audience here is not engineering managers deciding in your next tech stack, but programming language researchers.

Verdex 3y ago
> I think some folks are misreading the authors intentions(possibly due to aforementioned snark) Yes. It looks like the paper has some useful things to say. However, that abstract + intro is like walking into a wedding and splashing red paint on the bride and then announcing a bunch of very good reasons why the wedding should not continue. Nobody is going to be listening. Perhaps another way to say it is that nobody is misreading their intension. What they're doing is ignoring reasonable concerns said in an unreasonable way.
- dmkolobov 3y ago
  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.
- soqb 3y ago
  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.
  - dmkolobov 3y ago
    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).”

Verdex 3y ago

> I think some folks are misreading the authors intentions(possibly due to aforementioned snark) Yes. It looks like the paper has some useful things to say. However, that abstract + intro is like walking into a wedding and splashing red paint on the bride and then announcing a bunch of very good reasons why the wedding should not continue. Nobody is going to be listening. Perhaps another way to say it is that nobody is misreading their intension. What they're doing is ignoring reasonable concerns said in an unreasonable way.

dmkolobov 3y ago
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.
soqb 3y ago
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.
- dmkolobov 3y ago
  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).”