Fearless concurrency: Rust compile-time vs Go runtime

WHAT THIS TESTS It checks whether you can distinguish compile-time guarantees from runtime detection and articulate exactly which class of bug each language addresses.

A GOOD ANSWER COVERS Fearless concurrency in Rust means the compiler statically rejects programs that would have data races. Ownership ensures a value has one owner; borrowing rules allow either many shared references or one mutable reference but never both. Send (movable across threads) and Sync (shareable by reference across threads) are checked as bounds on concurrency primitives, so unsynchronized sharing of mutable state simply does not compile. You still must reach for Arc and Mutex to share, but misuse is a type error, not a runtime crash. Go's philosophy steers you to pass data through channels rather than locking shared memory, which reduces races by convention, but the compiler does not forbid sharing a pointer or map across goroutines. Data races in Go are detected only at runtime via the -race instrumentation during testing.

COMMON WRONG ANSWERS Claiming Go channels guarantee freedom from data races. Saying Rust prevents deadlocks or logical race conditions; it prevents data races, not all concurrency bugs. Treating Send and Sync as runtime checks.

LIKELY FOLLOW-UPS Does Rust prevent deadlocks? (No.) What is the cost of Go's race detector and why is it not enabled in production? How do you share state safely in each language?

ONE CONCRETE EXAMPLE In Go, two goroutines incrementing the same int without a mutex compiles and may corrupt the value; only running tests with go test -race reveals it. The equivalent Rust code, sharing a plain integer mutably across thread::spawn, fails to compile because the closure capturing &mut would not be Send and the borrow checker forbids the aliasing; you are forced to wrap it in Arc<Mutex<i32>> or use an atomic, at which point the access is provably safe.