Conversation

Why can't you just add a lifetime analysis/borrow checker to your favorite memory-unsafe language? Because Rust's static analysis does just one thing: makes sure you're following Rust's rules. But you aren't following those rules. So it won't work.

155

Patrick Walton

@pcwalton

Nov 14, 2021

What people who say they want a borrow check for C/C++/Zig/etc really want is a system that will automatically achieve memory safety without giving the programmer strict rules to follow. That technology exists and is very mature: garbage collection.

229

Tony "Abolish ICE" Arcieri

@bascule

Nov 14, 2021

Replying to

@pcwalton

…except for the part where pretty much all GC’d languages support mutable aliasing across threads

Replying to

and

Java does maintain memory safety despite having shared mutable state. Every field in Java would be considered atomic in C++11 or Rust but with an even weaker memory ordering than relaxed: llvm.org/docs/Atomics.h It doesn't do any more than preserving memory and type safety.

1:13 AM · Nov 14, 2021Twitter Web App

Replying to

and

Java has data races in the same sense that Rust has data races via atomics. It's not the kind of data race you get in C where it's totally unsafe with no guarantees and memory/type safety exists despite it. Java didn't take the shortcut that Go did where races can corrupt memory.

Replying to

and

Technically yeah, but the fact that Rust requires you to opt in to making values atomic (as opposed to Java where you can't even opt out) makes a big difference in practice.

Show replies