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!