Fun fact: Go compiler inserts a hidden check every time you index into a slice, and that check has a real cost. Take a simple function…
func get(s []int, i int) int { return s[i] }
Before it reads s[i], the compiler adds (internally) a comparison against len(s) and a jump to a panic if the index is out of range. That is two extra instructions on every single call, just to keep you safe from an out-of-bounds read.
Most of the time, this is a fair trade. Safety is, of course, worth a few cycles. But on a hot path, called millions of times a second, those cycles add up. If you know that the index will always be valid, you can skip the check entirely by using the following code to read the memory directly.
unsafe.Add(unsafe.Pointer(unsafe.SliceData(s)), i)
This way, the compiler does not need to compare, jump, or keep a panic path. It even collapses the function down to just a few assembly instructions.
This does not mean you should go ahead and start using unsafe everywhere. By default, the compiler is there to protect you, and the moment you reach for unsafe, that protection is gone. One mistake, and you have memory corruption.
Compilers are fun and interesting, aren’t they? Hope this helps.