[TimSchumann]

I’d argue that ‘a bunch of additional code’ to solve for memory safety is exactly what you’re doing in the ‘defining memory safety away’ example with Rust or Swift.

It’s just code you didn’t write and thus likely don’t understand as well.

This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.

[agarren]

That sounds a bit unfair. All that code that we neither wrote nor understood, I think in the case of Rust, it’s either the borrow checker or the compiler itself doing something it does best - i.e., “defining memory safety away”. If that’s the case, then labeling such tooling and language-enforced memory safety mechanisms as “a bunch of additional code…you didn’t write and…don’t understand” appears somewhat inaccurate, no?

[rk06]

It is quite fair as far as rust is concerned. For simple data structures, like doubly linked list,are hard problems for rust

[josephg]

> This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.

The borrow checker only runs at compile-time. It doesn't change the semantic meaning - or the resulting performance - of your code.

The borrow checker makes rust a much more difficult and frustrating language to learn. The compiler will refuse to compile your code entirely if you violate its rules. But there's nothing magical going on in the compiler that changes your program. A rust binary is almost identical to the equivalent C binary.