3 ms·
It sounds like you're shifting the goal posts pretty dramatically to me. Compare what you said above (which presumably prompted the reference to this paper) >
by burntsushi 9y ago
It sounds like you're shifting the goal posts pretty dramatically to me. Compare what you said above (which presumably prompted the reference to this paper)
> Writing a garbage collector runtime in Rust has most of the same problems in Rust as in C, because you have to write most of it in unsafe code, where Rust inherits much of C's undefined behavior w.r.t. pointers via LLVM. In short, you have largely the same problems and have added a hard dependency on Rust.
to the conclusions drawn in the cited paper. They sit in pretty stark contrast from where I'm standing.
- rbehrends 9y agoI'm not sure where you're getting the "goal post shifting" from. Writing "p.plus(n)" in their Rust code is not materially different from what "p + n" would be in C/C++ code. That the former is nominally safe code doesn't change the fact that the same unsafe Rust code gets inlined at every callsite. You could do the same in C++ by creating an Address class (similar to smart pointers) with restricted operations; these operations would not magically become safer just because they're inlined by the compiler rather than spelled out in the code.