This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.
(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)
Well, you're right about one thing: the fact that I've spent my career in software security doesn't make me "broad consideration". The cites I give on what "memory safe" means, though, do.
My argument has never been "memory safe means what I say it does because I say so", but I get how that's a much more convenient argument to knock down than the ISRG site built specifically to talk about this.
ISRG is wrong too, definition-wise. Go is not memory safe. It is much safer, and I wouldn’t fault you for taking a C codebase and porting it to Go to avoid memory safety problems, but that does not make it memory safe in the same way Rust et al are memory safe. This is the same way that MTE does not thwart all memory corruption but it stops a lot of them. I accept your premise that Go has brought memory safety over the line to where it is apparently easier to find logic bugs than exploit memory corruption, which is laudable since C(++) has never been able to do this and likely never will, but in line with the pedantry that started this whole chain of comments, it’s not memory safe.
u8 · · focus · HN ↗
OutOfHere · · focus · HN ↗
typical182 · · focus · HN ↗
See for example comments from tptacek like:
<a href="https://news.ycombinator.com/item?id=43335748">https://news.ycombinator.com/item?id=43335748
<a href="https://news.ycombinator.com/item?id=46028232">https://news.ycombinator.com/item?id=46028232
<a href="https://news.ycombinator.com/item?id=44672371">https://news.ycombinator.com/item?id=44672371
(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)
saagarjha · · focus · HN ↗
tptacek · · focus · HN ↗
My argument has never been "memory safe means what I say it does because I say so", but I get how that's a much more convenient argument to knock down than the ISRG site built specifically to talk about this.
saagarjha · · focus · HN ↗