True! What matters is that doPerson() doesn't get hold of a reference to the object which could cause escape. Since it doesn't get hold of a reference, it of course can't modify the object either. Had the call been doPerson(&person) it would have gotten a reference and Go would be forced to heap-allocate person. I agree that escape analysis is tricky because it is easier than one might think for objects to escape. That Go is better than Java at imprisoning objects I think is mostly because of different usage patterns between programmers of the two languages.