>> memory safe

> That's an incorrect assumption if you haven't audited the code.

Audit the code? Simply `grep unsafe`.

Well, perhaps `rg unsafe` if you want to use the rust counterpart to grep, ripgrep ;)

I guess Rust isn't guaranteed to be memory safe considering unsafe blocks but it does make it much more memory safe than languages which only offer manual memory management.

Just `leak` all your variables before they go out of scope ;)

I didn't know about that preamble, but I definitely got the vibe of "written on a write-only mindset"... just from reading their docs :) not to say trying to delve in the source code!

> That's an incorrect assumption if you haven't audited the code.

Even without an audit, the odds of a Rust project being memory safe are so much higher than in comparable languages.

Furthermore, Rust makes auditing so much easier by allowing you to concentrate on unsafe blocks.

That's a confusing statement -- JS/Node and Golang are comparable (memory safe) languages for API server backends.

Golang is only memory safe if you're not using the concurrency features. It doesn't protect against data races which can break safety.

Rust hasn't magically solved concurrency safety either, as linearity is not enough.

GC'd languages (Java, Go, Haskell etc) are safer than Rust by default, you just have the tradeoff of GC. Note that this isn't always a tradeoff as GCs can outperform static allocation in scenarios like large dynamic heaps.

Haskell is the safest for concurrency because of the strictly typed functional semantics.