Would Rust have prevented Heartbleed? Another look

Re:Would Rust have prevented Heartbleed? Another look by pcwalton on Tuesday March 17, 2015 @03:19PM (#9220536)

I can't speak to security as a whole, since security encompasses more than memory safety. But regarding memory safety, they're similar. Rust has an edge in that it can use hardware parallelism while remaining memory safe, while Go is not memory safe if GOMAXPROCS > 1. However, the memory-unsafe part of Go is a corner (racing on a map or slice) that hasn't caused any real-world security problems I'm aware of.

(Disclaimer: I'm a Rust developer.)

[ Parent | on HN ]

Re:Would Rust have prevented Heartbleed? Another look by slimsag on Tuesday March 17, 2015 @03:42PM (#9220751)

I generally agree with what you're saying here. The difference appears to be that Rust forces you on a compiler level to be safe of any potential race-condition.

Go doesn't enforce this on a compiler level -- but instead it encourages the use of sharing by communicating (over channels, where data races cannot occur), instead of sharing memory e.g. via a mutex (where you can run into a data race).

[ Parent | on HN ]

Re:Would Rust have prevented Heartbleed? Another look by steveklabnik on Tuesday March 17, 2015 @03:50PM (#9220825)

Important distinction: Rust forces you to be free of data races, which are a subset of race conditions. A very important subset, mind you, but they're different. It's not really possible to prevent general race conditions, like any form of logic error.

[ Parent | on HN ]