Maps and Memory Leaks in Go

Re:Maps and Memory Leaks in Go by pclmulqdq on Tuesday November 08, 2022 @08:51AM (#33518895)

The same goes for Rust and most other "safe" languages. They all have synchronization primitives that make it safe, but you need to use them - the compiler won't always tell you.

[ Parent | on HN ]

Re:Maps and Memory Leaks in Go by suremarc on Tuesday November 08, 2022 @09:19AM (#33519191)

I have no idea what you mean here. Data races are next to impossible in safe Rust.

[ Parent | on HN ]

Re:Maps and Memory Leaks in Go by Dobbs on Tuesday November 08, 2022 @10:13AM (#33519847)

That is basically the entire shtick of rust. That data is "owned", and only the owner can write. You can "borrow" something for read access, but if something is borrowed it can't be written to.

There are of course workarounds for this like reference counted wrappers and so on.

[ Parent | on HN ]

Re:Maps and Memory Leaks in Go by bilkow on Tuesday November 08, 2022 @10:49AM (#33520282)

For Rust specifically, the compiler does force safe programs to have no data races. That's actually what the ownership system, Send and Sync are about. If you manage to corrupt memory or have undefined behavior in safe Rust, that should be a compiler or library bug.

See https://doc.rust-lang.org/nomicon/races.html

[ Parent | on HN ]