It doesn't exactly, no. There are linters and a compiler-enforced check preventing unused variables. Overall it's pretty easy to accidentally drop errors or overwrite them before checking.

So no, it doesn't.

Well at least you shouldn’t be able to actually dereference a nil, right?

You'll get a runtime panic.

Hey, it's better than lurking undefined behavior and data corruption issues!

Doesn't keep your binary from crashing, though.

Sadly, and imo almost unforgivably in such a modern language, no

fwiw Go is simple, can be easily translated from TypeScript thanks to how similar it is, and has a GC, so you don’t have to learn what the hell a borrow checker is

No language forces to handle errors. Even Rust.

> No language forces to handle errors. Even Rust.

It does. If a function returns a Result or Option type, you can't just use its data; you have to either automatically propagate the error case upward, pattern match on both the success and error cases, or just use ".unwrap()" and explicitly choose to crash in the case of an error. There's no implicit crash like there is in a language that lets you dereference null pointers.

let _ = works fine in Rust.

That still can't cause a null pointer dereference.