3 ms·

I agree on the general point that go is simple and familiar, but it's absolutely not memory safe ( and as you said, channel is really not working as well as exp

by bsaul 10y ago

I agree on the general point that go is simple and familiar, but it's absolutely not memory safe ( and as you said, channel is really not working as well as expected in practice, unless you start using them as actor mailboxes, which i don't think was the original point). Actually, seeing all those panic on null pointers was really my first surprise when i started coding in go ( and really first disappointment).

kazinator 10y ago
Panics on null pointers don't indicate that the language isn't memory-safe. Lack of memory safety means that misuses of memory go undiagnosed, with unpredictable results. (Not to mention that they are allowed in the first place, with features like arrays that blindly allow oout of bound access.) A null pointer indicates a memory problem only if it is the field of a memory object that was wrongly overwritten with zeros, giving rise to the null value in an invalid way. If the null value was correctly assigned, then it isn't a problem in the memory safety category. If Go diagnoses all null pointers with panics, that makes it safer than C, whose implementations require on the virtual memory hardware to catch null pointers. An expression like ptr->member in C will onlyl segfault on a null ptr if the member displacement is within 4096 bytes, or whatever is the virtual memory page size. If memb is offset beyond the unmapped zero page, then some memory is silently accessed or overwritten. Not to mention that on systems without VM hardware, ptr->member just silently works when ptr is null, for any struct type. I don't program in Go, but as far as I know, panic is a kind of high level exception handling feature in Go. So it sounds like you should be able to write Go code which expects that null pointers will occur in some object field or parameters, and just use panic/recover to trap it all in one place instead. In C, you would need platform-specific coding to do anything similar, like catching a SIGSEGV in POSIX or a structured exception in Win32. Yuck!
deleted 10y ago
[deleted]
Animats 10y ago
Go is almost memory safe. There are two known areas where race conditions can break memory safety - maps (that was on purpose, as a possibly premature optimization) and shared slice descriptors (a design bug).

by bsaul 10y ago

kazinator 10y ago

Panics on null pointers don't indicate that the language isn't memory-safe. Lack of memory safety means that misuses of memory go undiagnosed, with unpredictable results. (Not to mention that they are allowed in the first place, with features like arrays that blindly allow oout of bound access.) A null pointer indicates a memory problem only if it is the field of a memory object that was wrongly overwritten with zeros, giving rise to the null value in an invalid way. If the null value was correctly assigned, then it isn't a problem in the memory safety category. If Go diagnoses all null pointers with panics, that makes it safer than C, whose implementations require on the virtual memory hardware to catch null pointers. An expression like ptr->member in C will onlyl segfault on a null ptr if the member displacement is within 4096 bytes, or whatever is the virtual memory page size. If memb is offset beyond the unmapped zero page, then some memory is silently accessed or overwritten. Not to mention that on systems without VM hardware, ptr->member just silently works when ptr is null, for any struct type. I don't program in Go, but as far as I know, panic is a kind of high level exception handling feature in Go. So it sounds like you should be able to write Go code which expects that null pointers will occur in some object field or parameters, and just use panic/recover to trap it all in one place instead. In C, you would need platform-specific coding to do anything similar, like catching a SIGSEGV in POSIX or a structured exception in Win32. Yuck!

deleted 10y ago

[deleted]

Animats 10y ago

Go is almost memory safe. There are two known areas where race conditions can break memory safety - maps (that was on purpose, as a possibly premature optimization) and shared slice descriptors (a design bug).