Defer statements run exactly at the moment of a function return (in lifo order). They are equivalent to wrapping the rest of the function body in a try / finally. They have to, since you can change the return value in a defer (by using named return values).

A "defer" statement invokes a function whose execution is deferred to the moment the surrounding function returns, either because the surrounding function executed a return statement, reached the end of its function body, or because the corresponding goroutine is panicking.

https://golang.org/ref/spec#Defer_statements

There might have been something else going on with your friend's code. Maybe the function he was using didn't return before running out of file descriptors?

I somehow completely misunderstood that from the Go documentation when first reading it; thank you for clarifying that.

There must have been some other leaking going on. He was using a largish library when he saw the leak and eventual crash so maybe it was due to improper pooling or C api calls? I'll have to ask him more about it.

Isn't it guaranteed to run at the exact point where the function in which "defer" was used returns?

I was wrong, apparently it is. Really wish there was a way to edit that comment now.